Linux OOM Killer 的触发机制

OOM Killer 在__alloc_pages_slowpath()彻底失败且out_of_memory()被调用时触发，非因“内存用光”，而是内核在page cache、swap等回收路径全失败后迫不得已的最后手段。

OOM Killer 是怎么被叫醒的？

它不是靠“内存用光了”才启动，而是内核在分配物理页失败时，走完所有回收路径后被迫触发的最后手段。关键节点是 out_of_memory() 函数被调用——这发生在进程真正写内存（缺页中断）且 __alloc_pages_slowpath() 无法再分配出页的时候。

• 系统先尝试回收 page cache、slab 等可再生内存；
• 若启用了 swap，还会尝试换出匿名页；
• 只有这些都失败，且 vm.panic_on_oom 不为 2 时，才会进入 OOM killer 流程。

注意：free -m 显示还有几百 MB “available”，照样可能触发 OOM——因为内核要求保留至少 min_free_kbytes 的空闲页（默认可能高达 1GB），这部分不参与分配，也不计入 available。

谁会被挑中杀掉？看的是 oom_badness() 得分

现代内核（2.6.36+）打分逻辑已大幅简化：badness = (进程当前使用内存 / 其允许使用的内存上限) × 1000 + oom_score_adj。也就是说，不是单纯比谁占得多，而是比“超限程度”。

• 普通进程 oom_score_adj 默认为 0；
• 容器或 cgroup 里运行的进程，上限就是 cgroup 的 memory.limit_in_bytes，哪怕只用了 199MB，上限设为 200MB，得分也会接近 1000；
• 系统关键进程（如 systemd）通常有负的 oom_score_adj（比如 -1000），几乎不会被选中。

查某个进程得分：直接读 /proc//oom_score；调高保护优先级：写负值到 /proc//oom_score_adj（例如 echo -500 > /proc/1234/oom_score_adj）。

cgroup 场景下 OOM 的真实归属容易误判

日志里写着 “Task in /mm_test/2 killed as a result of limit of /mm_test”，说明被杀的进程本身没超限，但它的父 cgroup /mm_test 达到了内存上限。这种嵌套限制下，oom_score 计算的“上限”是父级 limit，而不是进程所在子 cgroup 的 limit。

• 查 cgroup 内存使用：cat /sys/fs/cgroup/memory/mm_test/memory.usage_in_bytes 和 memory.limit_in_bytes；
• 如果 failcnt 在增长（cat /sys/fs/cgroup/memory/mm_test/memory.failcnt），说明该 cgroup 已反复触发内存分配失败；
• 别只盯着被杀进程的 RSS，要顺藤摸瓜查整个 cgroup 树的配额和实际用量。

为什么 overcommit_memory 会影响 OOM 触发时机？

这个参数控制内核对“内存申请”的信用额度：overcommit_memory=0（默认）表示按启发式规则判断是否允许过量分配；=1 表示永远允许；=2 表示严格禁止（总申请量 ≤ 物理内存 + swap）。

• 设为 2 后，malloc() 可能直接失败（返回 NULL），应用需自己处理；但好处是几乎不会走到 OOM killer 这步；
• 设为 0 时，看似安全，但一旦大量进程同时把虚拟内存“落实”为物理页，就极易集中触发 OOM；
• java 应用常因 -Xmx 设得过大，在 overcommit_memory=0 下成为 OOM killer 首选目标——它申请了大量虚拟内存，又很快全部触碰。

真正难排查的 OOM，往往不是内存真不够，而是 cgroup 配额卡死、min_free_kbytes 设置失当、或 overcommit 策略与应用行为错配。盯日志里的 gfp_mask 和 limit of 字样，比看 free 输出管用得多。