oom_score_adj=-1000 进程仍然被 OOM killer 选中的 systemd-oomd 规则

会。systemd-oomd 完全忽略 oom_score_adj=-1000，仅依据 cgroup v2 的 memory.current、memory.pressure、memory.low/high 及层级关系决策，不读取任何进程级 oom_score_adj 值。

systemd-oomd 会忽略 oom_score_adj=-1000 吗？

会。systemd-oomd 是独立于内核 OOM killer 的用户态内存管理器，它不读取或尊重进程的 /proc/PID/oom_score_adj 值。即使你手动设为 -1000（内核 OOM killer 的“永不 kill”标记），systemd-oomd 仍按自己的规则决策——它只看 cgroup 内存压力、使用量、增长速率等实时指标。

systemd-oomd 的实际判定依据是什么？

它基于 cgroup v2 路径下的内存统计，核心信号包括：

• memory.current：当前内存用量（是否超限）
• memory.pressure：内存压力值（尤其是 some 和 full 模式下的 10 秒均值）
• memory.low 和 memory.high：cgroup 级别配额（systemd-oomd 默认优先保护 memory.low 非零的 cgroup）
• 进程所属 cgroup 的层级关系（例如 /system.slice vs /user.slice）

它不会扫描所有进程，而是聚焦在压力最高、且未受 memory.low 保护的 cgroup 中选择目标。

如何让关键进程真正免于 systemd-oomd 杀死？

必须通过 cgroup 层级和资源策略干预，而非进程级 oom_score_adj：

• 将进程放入专用 cgroup（如 /mycritical.slice），并设置 MemoryLow=1G（非 0）——这会让 systemd-oomd 将其视为“受保护组”，大幅降低被选中的概率
• 确保该 slice 的父级（如 system.slice）没有整体内存限制压制它
• 禁用 systemd-oomd 对特定 slice 的监控（需谨慎）：
  sudo systemctl set-Property mycritical.slice MemoryAccounting=false（不推荐，仅临时调试用）
• 检查 /etc/systemd/system.conf.d/oomd.conf 中是否启用了 ManageOomScoreAdj=yes —— 这个选项只影响内核 OOM killer，对 systemd-oomd 完全无效

验证当前 systemd-oomd 行为的最简方法

直接查它的日志和决策依据：

• 看它最近 kill 了谁：journalctl -u systemd-oomd --since "1 hour ago" | grep -i "killed"
• 查某进程所在 cgroup 的压力：cat /sys/fs/cgroup/system.slice/myapp.service/memory.pressure
• 确认该 cgroup 是否设置了 memory.low：cat /sys/fs/cgroup/system.slice/myapp.service/memory.low（输出为 0 表示无保护）

systemd-oomd 的逻辑是“保护有 memory.low 的组，杀掉高压力且无 low 的组里的进程”，oom_score_adj 在这个流程里根本没出场机会。