OOM killer按cgroup局部决策，oom_score_adj仅在同cgroup内生效；badness得分由实际内存占用（含匿名页等）、cgroup压力系数等加权计算，-1000不等于免疫。

进程被 OOM kill 却已将 oom_score_adj 设为较低值（比如 -1000），仍被选中，往往不是因为配置没生效，而是内核在最终决策时引入了几个**不常被文档强调、但实际起决定性作用的隐藏规则**。

内存压力来源决定“谁该死”的优先级范围

OOM killer 不是全局扫描所有进程挑分最低的，而是先聚焦于**触发 OOM 的内存域（memory cgroup 或 NUMA node）内正在分配失败的进程所属的 cgroup**。即使你把某个后台服务的 oom_score_adj 调到 -1000，只要它恰好运行在当前内存紧张的 cgroup 里，而同 cgroup 内其他进程的分更高，它就可能成为备选——哪怕宿主机上还有大量空闲内存。

• 检查方式：cat /proc//cgroup 看进程归属；cat /sys/fs/cgroup/memory//memory.oom_control 查该 cgroup 是否已触发过 OOM
• 关键点：OOM 是按 cgroup 隔离粒度触发的，oom_score_adj 只在本 cgroup 内有效

实际内存占用 ≠ RSS，内核看的是 badness score 的完整计算逻辑

oom_score_adj 只是 badness 公式中的一个偏移项，真正得分由以下几项加权得出：

• 进程实际使用的内存页数（包括匿名页、文件缓存脏页、swapcached 页等） —— 这比 rss 更大，尤其对 mmap 大文件、使用 tmpfs 或有大量 page cache 的进程影响显著
• 进程的 CPU 时间权重（越老的进程权重略低） —— 但影响微弱，通常可忽略
• 是否为 superuser 进程（uid 0）会轻微降低得分
• oom_score_adj 值线性叠加，但有上下限（-1000 到 +1000） —— 设为 -1000 并不等于“免疫”，只是让基础分归零；若其内存占用是同类进程的 10 倍，仍可能高于其他轻量进程

某些内存类型会被“加倍惩罚”

内核对以下两类内存，在计算 badness 时会额外加重计分：

• 不可回收的匿名页（如 malloc 分配、堆栈、mmap(MAP_ANONYMOUS)） —— 因无法写回磁盘，回收代价最高
• 属于 memcg 且超出 memory.high 限制后继续增长的内存 —— 此时该 cgroup 已进入“压力模式”，其内进程的 badness 会被乘以一个增长系数（2x~4x），oom_score_adj 无法抵消该放大效应

例如：一个 Java 进程设了 oom_score_adj = -1000，但它的 heap 和 metaspace 占用 4GB 且全部是匿名页，同时所在 cgroup 已超 memory.high=3G，那么它的实际 badness 很可能远高于一个只占 500MB 但 oom_score_adj = 0 的 Nginx 进程。

确认是否真被 OOM killer 杀掉，而非其他机制

别默认日志里出现 “Killed process” 就是 OOM killer 所为：

• 检查 dmesg -T | grep -i "killed process" 输出中是否有 Out of memory: Kill process 开头的完整行 —— 这才是 OOM killer 日志
• 若只有 Memory cgroup out of memory 但无后续 kill 行，可能是 cgroup v2 的 memory.oom 控制器直接 freeze 进程，而非发送 SIGKILL
• 某些容器运行时（如 containerd）或 systemd 服务会拦截 OOM 事件并自行重启/退出，掩盖真实原因

不复杂但容易忽略。

https://www.php.cn/faq/2018908.html