Linux oom_score_adj 怎么控制进程被回收优先级

服务节点出现内存压力时，Linux OOM-killer 会在候选进程中选择更适合回收的对象。oom_score_adj 的作用是调整这个选择倾向：值越高，进程越容易成为候选；值越低，越不容易被选中。它不会把进程的内存上限改大或改小，所以不能替代 cgroup 的内存限制。

先弄清三个分数分别代表什么

排查时不要只看一个数字。oom_score 是内核根据进程当前内存、swap 使用以及所在资源范围计算出的候选分数；oom_score_adj 是用户空间提供的偏置；最终选择会参考两者的组合。OOM 发生在整机、cpuset、内存策略或内存控制器范围内时，“可用内存”这个上下文也会不同。

可以先用下面的命令读取目标 PID。示例只展示检查方法，不把输出当成固定运行结果。

PID=2480
# 同时查看基础分数、人工调整值和进程名称
printf 'oom_score='; cat "/proc/$PID/oom_score"
printf 'oom_score_adj='; cat "/proc/$PID/oom_score_adj"
grep -E '^(Name|Pid|VmRSS|Threads):' "/proc/$PID/status"
# 记录 cgroup 路径，判断 OOM 的资源边界
cat "/proc/$PID/cgroup"

按进程角色选择调整值

参数选择的核心不是“越低越安全”，而是明确谁可以牺牲。可重新计算的报表、缓存预热、一次性导入通常可以承受较高的回收倾向；主服务、任务调度器和负责清理资源的守护进程若被提前回收，可能让内存压力更难恢复。

Linux man-pages 给出的范围是 -1000 到 +1000。-1000 会让该任务始终报告 badness 0，等价于关闭 OOM-killer 对它的选择；这不是“永远不会结束”，也不会阻止管理员主动终止进程。

写入参数后如何确认没有改错 PID

临时调整适合故障处理或短时实验。写入前后都读取 PID 和数值，避免服务刚好重启后把策略写到了新旧进程之外。

PID=2480
NEW_ADJ=300
# 先确认目标仍是预期服务，再写入偏置
test -r "/proc/$PID/comm" && printf 'target=' && cat "/proc/$PID/comm"
printf '%s\n' "$NEW_ADJ" > "/proc/$PID/oom_score_adj"
# 反向读取，确认内核接受了设置
printf 'pid='; grep '^Pid:' "/proc/$PID/status"
printf 'oom_score_adj='; cat "/proc/$PID/oom_score_adj"
printf 'oom_score='; cat "/proc/$PID/oom_score"

如果写入返回 Permission denied，先检查当前用户、目标进程属主以及是否具备修改其他进程 OOM 调整值所需的权限。不要为了绕过权限直接把参数改到极端值。

重启、容器与内存限额的边界

/proc 下的设置绑定的是当前 PID。服务重启后 PID 可能变化，容器中还可能存在独立的 cgroup 内存边界，因此手工写一次不能当作持久化配置。生产环境应在 systemd 服务配置、容器启动参数或编排模板中声明策略，并把变更和回滚值一起纳入发布记录。

还要区分“让谁先被回收”和“最多允许使用多少内存”。前者用 oom_score_adj 表达优先级，后者用 cgroup 的内存限制表达容量。若真正问题是单个工作负载持续吃满内存，应先设定资源上限、观察回收和重启策略，再决定是否需要分数偏置。

相关问题

设置为 -1000 就能保证服务永不被杀吗？

不能。它只影响 OOM-killer 的选择分数，不能阻止管理员终止、服务管理器重启或其他故障处理动作。

正值越大，进程一定会第一个被回收吗？

不一定。最终判断还与进程实际内存、swap、资源控制范围以及同一范围内其他候选有关，正值只是把倾向往更容易被选中方向推。

为什么调了 oom_score_adj，内存占用没有下降？

因为它不是限额和清理命令。只有 OOM 选择发生时，它才影响候选偏好；要控制持续占用，应检查泄漏、缓存策略和 cgroup 上限。

参考资料：https://docs.kernel.org/mm/oom.html；https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj.5.html。