systemd-oomdOOMScoreAdjust配置全解析

对于一个文章开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《systemd-oomd OOMScoreAdjust 配置详解》，主要介绍了，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

systemd-oomd 从 systemd 单元静态配置读取 OOMScoreAdjust 值，不读取 /proc//oom_score_adj 运行时值；按 cgroup 内存压力筛选后，在该 cgroup 内按 OOMScoreAdjust 降序杀进程，值越高越优先被杀。

systemd-oomd 是怎么读取 OOMScoreAdjust 的

systemd-oomd 不读取 /proc//oom_score_adj 的运行时值，而是直接从 systemd 单元的配置中提取 OOMScoreAdjust 设置。它在进程启动时通过 cgroup 层级关系反向查找所属 unit，再读取该 unit 的静态配置值。这意味着：即使你用 echo -1000 > /proc//oom_score_adj 手动改了内核值，systemd-oomd 也完全无视——它只认 systemctl show -p OOMScoreAdjust myservice.service 返回的那个数。

• 值范围必须是 -1000 到 +1000；超出会被截断，但 unit 加载会报 warning
• 未显式设置时默认为 0（不是继承父 cgroup）
• 对 scope 单元（如 systemd-run 启动的临时任务）同样生效，只要它带 OOMScoreAdjust=

OOMScoreAdjust 在 systemd-oomd 中的实际排序逻辑

systemd-oomd 对进程打分时，并非简单按 OOMScoreAdjust 值升序杀，而是先过滤出内存压力最大的 cgroup（基于 memory.current 和 memory.low 差值），再在该 cgroup 内部按 OOMScoreAdjust 降序排列——也就是优先杀 OOMScoreAdjust 更高的进程。这点容易误解：设成 -1000 是“保命”，+500 是“速杀”。

• 同 unit 下多个进程共享同一 OOMScoreAdjust 值，无内部区分
• 若两个 unit 的 OOMScoreAdjust 相同，则 fallback 到内存占用比例（memory.current / cgroup limit）
• user.slice 下的桌面进程（如 gnome-shell）默认没设值，即 0 分，比设了 -500 的后台服务更容易被选中

如何验证 systemd-oomd 是否真用了你的 OOMScoreAdjust

最可靠的方式不是看 journalctl -u systemd-oomd，而是查 oomd 实际决策日志和对应 unit 的实时状态。systemd-oomd 默认只在 kill 动作发生后才记一条摘要，不记录候选排序过程。

• 启用调试日志：sudo systemctl edit systemd-oomd，加 [Service] Environment=SYSTEMD_OOMD_LOG_LEVEL=4，重启后 journalctl -u systemd-oomd -f 可见详细评分过程
• 确认 unit 已加载配置：systemctl show --property=OOMScoreAdjust,MemoryCurrent,MemoryMax myapp.service
• 手动触发测试（慎用）：sudo systemd-run --scope --scope --property=OOMScoreAdjust=800 -- bash -c 'dd if=/dev/zero of=/dev/null bs=1M'，观察是否优先被 kill

常见配置陷阱与兼容性注意点

很多用户把 OOMScoreAdjust 放错位置，或忽略 cgroup v2 的前提条件，导致配置静默失效。

• 必须在 service/scope 的 [Service] 或 [Unit] 段里写，不能放在 [Install] 或全局 /etc/systemd/system.conf
• 仅在 cgroup v2 模式下生效；检查 cat /proc/1/environ | tr '\0' '\n' | grep systemd.unified_cgroup_hierarchy 应返回 1
• 容器环境（如 podman、docker）中，若容器 runtime 自己管理 cgroup，则 systemd-oomd 通常看不到容器内进程，OOMScoreAdjust 无效
• OOMScoreAdjust 不影响内核原生 OOM killer，仅作用于 systemd-oomd 这个用户态守护进程

实际调优时，别只盯着数值大小——真正关键的是厘清 cgroup 层级归属和内存压力源。一个设了 -900 的数据库进程，如果被错误地塞进 default.target 而不是独立的 database.slice，它的保护效果可能还不如一个正确切片但只设 -500 的服务。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《systemd-oomdOOMScoreAdjust配置全解析》文章吧，也可关注golang学习网公众号了解相关技术文章。