Linux怎么查看内存分配失败导致挂起

进程出现挂起，常见原因通常就两类：要么被 OOM Killer 直接干掉了，要么卡在 D 状态里，迟迟等不到内存分配。排查时可以先用 ps 看 STATE 是否为 D，再结合 wchan 是否停在 mm_page_alloc 这类函数，以及 /proc/[PID]/stack 里有没有 try_to_free_pages，基本就能把问题坐实。还有一种情况特别容易误判：明明 free 看着还有余量，分配却还是失败。根子往往不在“总量不够”，而在于内存碎片、zone 分布失衡，或者 min_free_kbytes 设得过高，最终导致连续页请求始终拿不到满足条件的内存。

进程因内存分配失败而挂起，通常不是“静默挂起”，而是已被内核干预——要么被 OOM Killer 杀掉，要么卡在系统调用（如 brk、mmap）上等待内存，表现为 D 状态（uninterruptible sleep），此时 ps 显示 STAT 列为 D，且无法被 kill -9 终止。

怎么确认进程卡在内存分配上？

先看进程状态是否为不可中断的 D：

• 运行 ps -eo pid,comm,state,wchan:20,vsz,rss,time --sort=-rss | head -10，重点关注 STATE 列是 D 还是 R/S
• 若为 D，再查 WCHAN（等待的内核函数）：常见值如 mm_page_alloc、__alloc_pages_slowpath、do_mmap，直接指向内存分配阻塞
• 配合 cat /proc/[PID]/stack 查看内核栈（需 root）：如果末尾出现 wait_event_killable + try_to_free_pages 或 oom_killer_disable，基本可断定正卡在内存回收或 OOM 处理路径上

为什么 free 显示还有内存却仍分配失败？

这不是“没内存”，而是“没有满足条件的内存”：

• a vailable 值低 ≠ 物理页全满，但可能因内存碎片（尤其低阶页）、zone 不平衡（如 DMA zone 耗尽）、或 min_free_kbytes 保护水平过高，导致无法分配连续页（比如 mmap 请求大块内存、或内核模块申请 kmalloc(1MB)）
• slabinfo 中某 cache（如 size-4096）num_slabs 高但 shareda vail 接近 0，说明 SLAB 缓存已碎片化，无法满足新分配
• 检查 cat /proc/buddyinfo：若 Order 9（2MB）或 Order 10（4MB）对应数字为 0，而程序恰好需要这么大的连续页，就会失败并挂起

如何快速验证是不是 OOM Killer 干预了？

别只看 dmesg 最后几行，要查完整 OOM 上下文：

• 执行 dmesg -T | grep -A 20 -B 5 "Out of memory"，注意时间戳是否与进程挂起时间吻合
• 关键线索不止是 Kill process，更要关注前几行：Mem-Info: 后面的 active_anon、inactive_file、unevictable 比例，以及 pagesets 是否显示 lowmem_reserve[] 触发保护
• 若日志里有 Task in /system.slice has been killed，说明 cgroups 内存限制触发了本地 OOM（memory.oom_control），而非全局 OOM Killer

挂起后还能抢救吗？

绝大多数情况下不能“唤醒”，只能释放资源让内核继续：

• 若进程处于 D 状态且 WCHAN 是内存分配相关函数，唯一可靠方式是释放内存压力源：杀掉其他高 RSS 进程、清缓存（echo 3 > /proc/sys/vm/drop_caches）、关闭 swap（swapoff -a 可能反而加重压力，慎用）
• 不要尝试 sysctl vm.panic_on_oom=1 或重启内核参数——这只会让问题更不可控
• 真正该做的，是在挂起发生前就监控 /proc/[PID]/status 中的 MMU 相关字段（如 Threads、voluntary_ctxt_switches 异常飙升），或用 bpftrace 抓 kmalloc/vm_brk 失败事件

“挂起”这件事，本质上是内核触发的一种防御性冻结机制，本身并不能简单算作 bug；可一旦反复发生，问题往往就不在“挂起”本身了，而在于应用的内存使用模式和系统配置明显对不上号。典型情况包括：某个 C++ 程序频繁使用 mmap(MAP_HUGETLB)，却根本没有预留 hugepage；或者 Ja va 应用开启了 -XX:+UseLargePages，但 /proc/sys/vm/nr_hugepages 仍然是 0。