systemd-oomdOOMScoreAdjust配置全解析

本文深入解析了 systemd-oomd 如何基于静态单元配置中的 OOMScoreAdjust 值（而非内核运行时的 /proc/*/oom_score_adj）实现精准、可控的内存压力下进程终止策略：它先定位内存压力最高的 cgroup，再在其中按 OOMScoreAdjust 降序优先杀死高分值进程（+1000=最易杀，-1000=最强保护），并强调该机制仅在 cgroup v2 下生效、不适用于容器内进程、且实际效果高度依赖正确的 cgroup 切片归属与配置位置——帮你避开常见陷阱，真正掌握 systemd-oomd 的调优逻辑。

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学习网公众号，给大家分享更多文章知识！