systemd-oomd 杀错进程或不杀的优先级 / score_adj 配置经验

systemd-oomd 杀错进程主因是 score_adj 未生效，常见于 ProtectProc 干扰、容器运行时重置、服务类型配置不当；oomd 不触发则多因 cgroup v2 未启用或进程未纳入 systemd 管理；其 kill 决策综合内存占用与 score_adj 加权计算，并非越负越安全。

systemd-oomd 杀错进程：score_adj 被忽略的常见原因

systemd-oomd 不按预期调整进程 OOM score，多数是因为 score_adj 值未被真正应用。它只读取 /proc/$PID/oom_score_adj 的当前值，而该值可能被 systemd 服务配置、容器运行时（如 runc）、或进程自身调用 setpriority() / prctl(PR_SET_OOM_SCORE_ADJ, ...) 覆盖。

典型现象是：你给 mysqld.service 设置了 OOMScoreAdjust=-900，但 systemctl show mysqld | grep OOM 显示正确，cat /proc/$(pidof mysqld)/oom_score_adj 却是 0 或 -1000 —— 这说明进程启动后又被重置了。

• 检查是否启用了 ProtectProc=（尤其是 ProtectProc=yes 或 protectProc=strict），它会阻止子进程修改 /proc/$PID/oom_score_adj，但也可能干扰 systemd 写入
• 容器场景下，runc 默认将 oom_score_adj 设为 -999；若容器内进程再调用 prctl，结果不可控
• OOMScoreAdjust= 必须写在 service unit 的 [Service] 段，且服务需用 Type=simple 或 Type=forking（非 Type=notify 启动后才 fork 的情况要小心主进程 PID 变更）

systemd-oomd 不触发杀进程：内存压力检测失效的配置盲区

systemd-oomd 默认只监控 cgroup v2 层级下的 memory.current 和 memory.low，若你的系统没启用 cgroup v2、或目标进程不在 systemd 管理的 scope/service 下（比如直接 nohup ./app & 启动），oomd 根本看不见它。

验证方式：systemctl status systemd-oomd 看是否 active；再执行 systemd-run --scope --scope-Property=MemoryLow=1G sleep 300，然后 cat /sys/fs/cgroup/system.slice/systemd-run*.scope/memory.current 是否有数值变化。

• 确保内核启动参数含 systemd.unified_cgroup_hierarchy=1（debian/ubuntu 22.04+ 默认开启，centos/RHEL 8/9 需手动确认）
• 非 systemd 启动的进程，可手动绑定进 cgroup：echo $PID > /sys/fs/cgroup/mygroup/cgroup.procs，但 oomd 不会自动管理该 group，需配 OOMScoreAdjust= 到对应 scope unit
• oomd 默认每 2 秒采样一次，若内存 spike 小于 500ms，可能漏判；可通过 OOMPolicy=continue + 日志观察 journalctl -u systemd-oomd -f 确认是否真没触发

调整 score_adj 的实际优先级逻辑：不是越负越安全

systemd-oomd 的 kill 决策不单看 oom_score_adj，而是综合 memory.current、memory.pressure 和 oom_score_adj 计算加权得分。一个 oom_score_adj = -900 但占了 80% 内存的进程，仍可能比 oom_score_adj = 0 占 5% 内存的进程先被杀——因为 oomd 优先选“释放内存最多且代价最小”的目标。

• oom_score_adj 范围是 -1000 ~ +1000，-1000 表示永不 kill（仅限内核 OOM killer；systemd-oomd 会跳过 -1000，但 -999 仍可能被选中）
• 建议保守设置：核心数据库设 OOMScoreAdjust=-800，缓存服务设 -500，批处理脚本设 +300，避免极端值导致调度器失去调节空间
• 不要依赖 OOMScoreAdjust 把某个进程“绝对保命”，oomd 的设计哲学是“可控牺牲”，真到内存耗尽边缘，所有非 -1000 进程都可能被评估

验证和调试 systemd-oomd 行为的最小可行步骤

别靠猜，用三步快速定位问题出在哪一层：cgroup 可见性 → oomd 采样 → score_adj 生效链路。

• 查进程归属：cat /proc/$PID/cgroup 看是否在 system.slice/xxx.service 下；不是？oomd 不管它
• 查 oomd 日志：journalctl -u systemd-oomd --since "1 hour ago" | grep -E "(kill|score|memory)"，关注 Choosing to kill process 后面的 PID 和 score
• 查最终生效值：cat /proc/$PID/status | grep OOM（注意是 OOMScoreAdj 字段，不是 oom_score），这个才是 oomd 实际读的值

最常被忽略的是：systemd-oomd 的决策日志默认等级是 info，而很多系统把 journald 的 level=notice，导致关键 kill 日志被过滤掉——改 /etc/systemd/system.conf 中的 LogLevel=info 并重启 systemd-journald 才能看到全貌。