systemd-oomd 不依赖 /proc/*/oom_score_adj 直接排序，而是综合 OOMScoreAdj、cgroup v2 内存压力、cgroup 层级权重及关键进程标记来判定优先级；要避免被杀，需设 OOMScoreAdjust=-1000 并配合 MemoryMax、MemoryLow、独立 cgroup 及启用 systemd-oomd。
systemd-oomd 的进程优先级判定依据是 OOMScoreAdj 和内存压力信号
systemd-oomd 不读取传统内核 OOM killer 的 /proc/*/oom_score_adj 值做直接排序，而是结合：
– 进程的 OOMScoreAdj 设置（范围 -1000 ~ +1000）
– 实时内存压力指标（来自 cgroup v2 memory.pressure）
– 进程所属 cgroup 的层级与权重（如用户会话、服务 scope）
– 是否为“关键进程”（例如标记了 MemoryLimit= 或 OOMScoreAdjust= 的 service）
它默认更倾向杀死低优先级、高 内存占用、且处于高压力 cgroup 中的进程，而非单纯看谁的 OOMScoreAdj 数值最高。
如何让某个进程「不被 systemd-oomd 杀」：设负值 + 锁定 cgroup 资源
仅设 OOMScoreAdjust=-1000 不够可靠——systemd-oomd 会降权但不跳过；必须配合资源约束和 cgroup 稳定性措施：
- 在对应 unit 文件中设置
OOMScoreAdjust=-1000（注意是负值，越小越不易杀） - 显式限制内存上限：
MemoryMax=2G（避免该进程拖垮整个 cgroup） - 启用内存压控：
MemoryLow=512M，让内核提前回收其 page cache，降低压力传导 - 确保该 service 运行在独立 scope 或 slice 下（避免被父 cgroup 的压力波及）
- 禁用自动 OOM 处理（谨慎）：
OOMPolicy=continue（仅适用于你完全接管内存管理的场景）
为什么 改了 OOMScoreAdj 却没效果？常见配置盲区
systemd-oomd 只作用于启用 cgroup v2 且启用了 SystemMaxUse= 类内存策略的系统；以下情况会导致配置失效：
- 系统仍运行在 cgroup v1 模式（检查
cat /proc/1/environ | tr ' ' 'n' | grep systemd中是否有systemd.unified_cgroup_hierarchy=1） - unit 启动后被动态移动到其他 cgroup（例如被
systemd-run --scope临时包裹，或桌面环境 session manager 重挂载） -
OOMScoreAdjust=写在了错误的 unit 类型里：对.service有效，但对.slice或.scope无效（后者需用DefaultLimitMEM=或 cgroup 属性接口） - systemd-oomd 本身被禁用：
sudo systemctl is-active systemd-oomd返回inactive，需sudo systemctl enable --now systemd-oomd
验证和调试：别只看日志，要查实时 score 和 pressure
journalctl 日志（如 systemd-oomd[……]: Killed process ……）只告诉你“结果”，无法反映决策逻辑。真要定位误杀，得实时比对：
- 查当前各进程 OOMScoreAdj：
awk '/^OOMScoreAdj:/ {print $2}' /proc/*/status 2>/dev/null | sort -n | tail -10 - 查所属 cgroup 的压力等级：
cat /sys/fs/cgroup/user.slice/memory.pressure（关注some和full字段的 10s/60s/600s 均值） - 看 systemd-oomd 内部评估：
sudo systemd-oomdctl status（显示当前活跃的 high-pressure cgroups 和 top candidate 进程） - 模拟压力测试：
stress-ng --vm 2 --vm-bytes 3G --timeout 30s，再立刻执行上述检查
真正容易被忽略的是：systemd-oomd 的评分每 2 秒刷新一次，且会平滑衰减历史压力；短时峰值可能被忽略，而持续中低压力却可能触发更激进的回收——这和传统 OOM killer 的瞬时快照逻辑完全不同。
