会。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.slicevs/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 在这个流程里根本没出场机会。
