systemd-oomd 从 systemd 单元静态配置读取 OOMScoreAdjust 值，不读取 /proc//oom_score_adj 运行时值；按 cgroup 内存压力筛选后，在该 cgroup 内按 OOMScoreAdjust 降序杀进程，值越高越优先被杀。
systemd-oomd 是怎么读取 OOMScoreAdjust 的
systemd-oomd 不读取 /proc/ 的运行时值，而是直接从 systemd 单元的配置中提取 OOMScoreAdjust 设置。它在进程启动时通过 cgroup 层级关系反向查找所属 unit，再读取该 unit 的静态配置值。这意味着：即使你用 echo -1000 > /proc/ 手动改了内核值，systemd-oomd 也完全无视——它只认 systemctl show -p OOMScoreAdjust myservice.service 返回的那个数。
- 值范围必须是 -1000 到 +1000；超出会被截断，但 unit 加载会报 warning
- 未显式设置时默认为 0（不是继承父 cgroup）
- 对 scope 单元（如
systemd-run启动的临时任务）同样生效，只要它带OOMScoreAdjust=
OOMScoreAdjust 在 systemd-oomd 中的实际排序逻辑
systemd-oomd 对进程打分时，并非简单按 OOMScoreAdjust 值升序杀，而是先过滤出内存压力最大的 cgroup（基于 memory.current 和 memory.low 差值），再在该 cgroup 内部按 OOMScoreAdjust 降序排列——也就是优先杀 OOMScoreAdjust 更高的进程。这点容易误解：设成 -1000 是“保命”，+500 是“速杀”。
- 同 unit 下多个进程共享同一
OOMScoreAdjust值，无内部区分 - 若两个 unit 的
OOMScoreAdjust相同，则 fallback 到内存占用比例（memory.current/ cgroup limit） - user.slice 下的桌面进程（如
gnome-shell）默认没设值，即 0 分，比设了 -500 的后台服务更容易被选中
如何验证 systemd-oomd 是否真用了你的 OOMScoreAdjust
最可靠的方式不是看 journalctl -u systemd-oomd，而是查 oomd 实际决策日志和对应 unit 的实时状态。systemd-oomd 默认只在 kill 动作发生后才记一条摘要，不记录候选排序过程。
- 启用调试日志：
sudo systemctl edit systemd-oomd，加[Service] Environment=SYSTEMD_OOMD_LOG_LEVEL=4，重启后journalctl -u systemd-oomd -f可见详细评分过程 - 确认 unit 已加载配置：
systemctl show --property=OOMScoreAdjust,MemoryCurrent,MemoryMax myapp.service - 手动触发测试（慎用）：
sudo systemd-run --scope --scope --property=OOMScoreAdjust=800 -- bash -c 'dd if=/dev/zero of=/dev/null bs=1M'，观察是否优先被 kill
常见配置陷阱与兼容性注意点
很多用户把 OOMScoreAdjust 放错位置，或忽略 cgroup v2 的前提条件，导致配置静默失效。
- 必须在 service/scope 的
[Service]或[Unit]段里写，不能放在[Install]或全局/etc/systemd/system.conf - 仅在 cgroup v2 模式下生效；检查
cat /proc/1/environ | tr '\0' '\n' | grep systemd.unified_cgroup_hierarchy应返回1 - 容器环境（如 podman、docker）中，若容器 runtime 自己管理 cgroup，则 systemd-oomd 通常看不到容器内进程，
OOMScoreAdjust无效 -
OOMScoreAdjust不影响内核原生 OOM killer，仅作用于 systemd-oomd 这个用户态守护进程
实际调优时，别只盯着数值大小——真正关键的是厘清 cgroup 层级归属和内存压力源。一个设了 -900 的数据库进程，如果被错误地塞进 default.target 而不是独立的 database.slice，它的保护效果可能还不如一个正确切片但只设 -500 的服务。
