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 才能看到全貌。
