Linux systemd.exec OOMScoreAdjust怎样调整服务被 OOM 选择的优先级

systemd 的 OOMScoreAdjust= 用来调整服务进程参与 Linux 内核 OOM 选择时的倾向。值越大，越容易被选中；负值降低被选中的倾向。把配置写在服务的 [Service] 段，并让服务以新配置重新启动，才能对新启动的进程应用该设置。它不是内存配额，也不保证服务在任何终止机制下都能存活。

systemd 官方文档地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

最小写法放在服务的Service段

假设一台主机同时运行在线查询服务和可重做的离线任务，希望内存紧张时降低在线服务被内核 OOM 选中的倾向。可以为已有的示例服务 query-api.service 添加 drop-in：

[Service]
# 示例：适度降低内核OOM选择倾向；-250不是通用推荐值
OOMScoreAdjust=-250

该值允许的整数范围是 -1000 到 1000。0 表示不额外施加正负调整；如果没有显式设置，进程默认继承服务管理器的调整级别，通常为 0。不要看到服务重要，就把所有服务都设置为 -1000；这会改变整机内存耗尽时的选择空间。

这项能力并非本文宣告的新版本特性。对现有部署更有用的切入点，是将服务角色落实为可以解释的参数：关键在线请求是否需要相对保护，哪些任务允许重做，以及其他服务能否承担更高的被终止风险。

先分清调整值和最终得分

/proc/PID/oom_score_adj 表示调整量，/proc/PID/oom_score 表示内核导出的当前得分。两者不是同一字段：调整量参与评分，但最终选择仍与进程资源使用情况和发生 OOM 的上下文有关。

因此，-250 不能解释为“少占250MB”，也不能解释为“降低25%的被杀概率”。这不是概率接口。对两个服务分别设置 -250 和 +250，也不意味着无论资源使用和候选范围如何，后者都一定先被终止。

OOM 的候选范围同样关键。整机内存耗尽，与某个内存控制组达到限制，涉及的资源范围不同。如果在线服务的 cgroup 自己耗尽限额，不能期待内核一定改选另一组无关的离线服务来解决它的问题。调整选择倾向不等于跨组转移内存预算。

-1000 是特殊值，用于让相应任务不被内核 OOM killer 选中；它并不阻止管理员发送信号、systemd-oomd 采取动作，或应用因分配失败而自行退出。它也不会让已经耗尽的内存重新出现。

重载配置后查看新进程的实际值

建议使用 drop-in 管理自定义设置，避免直接修改发行版提供的主 unit 文件。下面的命令供读者在自己的目标主机上操作，示例服务名应替换为真实名称；重启要安排在允许服务重启的时段。

# 创建或编辑服务drop-in，在编辑器中写入上面的Service配置
sudo systemctl edit query-api.service

# 重读unit配置；仅daemon-reload不会改写现有进程的调整值
sudo systemctl daemon-reload
sudo systemctl restart query-api.service

# 查看服务管理器加载的配置及当前主进程PID
systemctl show query-api.service -p OOMScoreAdjust -p MainPID
systemctl cat query-api.service

配置层显示正确，还需要把它与当前运行进程区分开。下面读取主进程的两个字段，不会主动制造内存压力：

# MainPID为0表示没有可用主进程，不能继续读取对应proc目录
service_pid=$(systemctl show query-api.service --property=MainPID --value)
case "$service_pid" in
  ""|0|*[!0-9]*)
    echo "服务没有可检查的主进程PID" >&2
    exit 1
    ;;
esac

# 进程可能在读取前退出；失败时重新取得MainPID，不沿用旧数字
cat "/proc/$service_pid/oom_score_adj"
cat "/proc/$service_pid/oom_score"

第一个文件应体现目标进程当时的调整量；第二个得分不要求等于它。若 proc 路径消失，应先看服务是否重启或已退出。主进程的结果也不能代表所有工作进程：多进程服务需要结合实际进程集合判断，应用自身也可能调整相关值。

如果服务启动失败并出现 206/OOM_ADJUST，systemd 文档将它定义为调整 OOM 设置失败。此时先看服务日志和运行环境权限，而不是继续把参数调得更负。普通用户管理器、容器与系统服务的可用权限不一定相同，降低调整值受到内核权限规则约束。

内存限制和systemd-oomd另有职责

OOMScoreAdjust= 调整进程在内核 OOM 评分中的倾向；MemoryHigh= 和 MemoryMax= 属于 cgroup 资源控制，解决服务内存预算问题。前者不能替代后者，降低得分也不能修复内存泄漏或不受控的并发分配。

systemd-oomd 则是用户态组件，利用 cgroup v2 和内存压力信息作决策，可能在内核 OOM 发生之前选择 cgroup 并终止其中的进程。它的候选偏好由 ManagedOOMPreference= 等设置控制，不能简单把进程的 -1000 当作对它的免除规则。该设置本身还有权限、所有权和扩展属性等适用条件，需要按本机文档部署。

OOMPolicy= 的职责又不同：它描述服务管理器在服务进程被 OOM 终止后如何响应。它不是评分输入。排查时应先辨认究竟是内核 OOM、systemd-oomd，还是应用自己退出，再选择要调整的配置。

按服务角色决定并保留回退

相较于临时写入某个 PID 的 proc 文件，unit 配置更适合表达服务后续启动时的默认意图；临时写入的目标进程一旦退出，就不应被当作服务永久策略。采用时记录选值原因、服务角色和回退配置，避免几年后只剩一个没人能解释的负数。

需要撤回本次调整时，在同一 drop-in 中删除本次添加的 OOMScoreAdjust 行，再重载配置并安排重启。若本来已有其他层级设置，删除后会回到其他配置或继承值；显式写 0 则表示主动采用零调整，两种动作不完全相同。不要为删一行配置而顺带清除其他业务 drop-in。

设置负值后服务仍被杀，说明参数失效了吗？

不一定。先核对进程实际值与终止来源，再看是否属于局部内存限制或用户态oomd动作。负值只降低相应评分倾向，不承诺存活。

OOMScoreAdjust和Nice能互相替代吗？

不能。Nice涉及CPU调度优先级，OOMScoreAdjust涉及内存耗尽时的候选评分，服务变慢和被OOM终止要分别诊断。

能通过拉满内存来确认效果吗？

不要把线上服务的首次配置核对变成故障演练。先读配置与proc实际值；若确需研究OOM行为，应使用有明确资源边界和恢复方案的独立环境，并将结果限定在相同内核、cgroup和负载条件下。

接口参考：https://www.kernel.org/doc/html/latest/filesystems/proc.html；https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html；https://www.freedesktop.org/software/systemd/man/latest/systemd-oomd.service.html。