linux内存分配失败无统一日志，需通过dmesg查oom killer标记、/proc/meminfo比对commitlimit与committed_as、memavailable评估真实可用内存、slab/numa/cgroup等多维度排查隐性压力源。
Linux 不会自动记录“内存分配失败”事件到统一日志，也没有类似 dmesg 那样集中输出的“分配失败日志”。所谓“分配失败”，本质是内核在页分配路径（如 alloc_pages）中返回 NULL，而这一过程通常**不打日志**——除非触发了 OOM killer 或显式配置了调试选项。所以“查看记录”实际是排查**失败原因留下的痕迹**，而非翻阅某份失败日志。
查 OOM killer 是否已介入
这是最直接的信号：一旦内核判定无法满足内存请求且无回收余地，就会启动 OOM killer 并在 dmesg 中留下明确标记。
- 运行
dmesg -T | grep -i "killed process"，看是否有类似[Tue Jul 8 14:22:03 2026] Killed process 12345 (java) total-vm:423456kB, anon-rss:189024kB, file-rss:0kB的输出 - 注意时间戳是否贴近业务报错时刻；
-T参数让时间可读，避免依赖uptime换算 - 若没匹配到，不代表没发生 OOM——某些内核配置（如
vm.oom_kill关闭）或 cgroup 限制下，进程可能直接收到-ENOMEM而不触发 kill
检查 overcommit 配置是否拦住分配
当 /proc/sys/vm/overcommit_memory 设为 2 时，系统按 CommitLimit 严格限制虚拟内存总量，即使物理内存充足，fork() 或大块 mmap() 也可能静默失败。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 确认当前值：
cat /proc/sys/vm/overcommit_memory—— 若为2，继续查CommitLimit和Committed_AS - 对比关键字段：
grep -E "^(CommitLimit|Committed_AS)" /proc/meminfo，若Committed_AS接近甚至超过CommitLimit，就是 overcommit 拦截了 - 临时修复：
echo 0 > /proc/sys/vm/overcommit_memory（仅测试用，生产需评估风险）
定位隐性内存压力源（非空闲内存不足）
很多“分配失败”根本不是因为 free 显示的空闲内存少，而是内核无法凑出连续页帧，或受制于其他子系统限制。
- 看
MemAvailable（比free的available更准）：grep MemAvailable /proc/meminfo，若远低于预期，说明 page cache、slab 等不可快速回收 - 查 slab 占用：
grep -i "slab" /proc/meminfo，若SReclaimable很小但SSlab很大，说明 dentry/inode 缓存淤积，常见于大量小文件操作 - 检查 NUMA node 不均：
numastat -m，若某 node 的Free极低而其他 node 充裕，进程绑核或跨 node 分配会失败 - 确认 cgroup 限值：
find /sys/fs/cgroup -name memory.usage_in_bytes 2>/dev/null | xargs -I{} sh -c 'echo {}; cat {}' | grep -A1 "memory.limit_in_bytes"，OOM 可能发生在容器或服务级 cgroup 内
从进程侧捕获 -ENOMEM 返回（应用层可观测点）
内核不记日志，但应用调用 malloc/mmap 失败时会返回 NULL 或设置 errno = ENOMEM。这是唯一可靠的“失败记录”来源，但需主动埋点或复现。
- 对 C/C++ 程序，确保所有
malloc/calloc/mmap调用后检查返回值，不要只依赖new的异常（C++ 默认 new 不抛异常，除非用nothrow） - Java 应用可通过
-XX:+PrintGCDetails观察 GC 后仍无法分配，间接反映内存碎片或堆外分配失败 - 用
strace -e trace=brk,mmap,mremap,munmap -p PID实时抓取某进程的内存系统调用，看到mmap(...)<code> 返回 <code>-ENOMEM即为直接证据
真正难的不是“查哪条日志”，而是理解失败发生在哪一层：是全局 overcommit 拦截、cgroup 限额、NUMA 局部耗尽、slab 泄漏，还是应用自己没检查返回值就用了 NULL 指针。每个环节留下的线索类型不同，得根据现象反推路径，而不是指望一个命令吐出“分配失败时间线”。
