systemd-oomd 怎么配：用 PSI 提前回收高压服务并验证候选 cgroup

一台跑着多个 systemd 服务的 Linux 主机，内存压力上来时最怕两件事：内核直接触发 OOM 杀进程，或者运维只盯着 free -h，直到业务服务连片掉线。systemd-oomd 的思路完全不一样，它读取 cgroup v2 和 PSI（压力 stall 统计信息），在系统还没完全失去响应前，优先处理我们提前标记好的可回收的子服务。

先判断：这次压力场景适合交给 systemd-oomd 吗

systemd-oomd 是用户态的 OOM 处理器，不是给每个服务单独设置 MemoryMax= 的替代品。它用 PSI 观察任务因为内存回收被阻塞延迟的时长，再对照预设的压力阈值挑选候选 cgroup。适合用它的场景，是有明确的低优先级服务、核心业务要优先保活，并且能接受某一个子服务被整体终止的情况。

先把基础条件核对一遍：

stat -fc %T /sys/fs/cgroup
test -r /proc/pressure/memory && cat /proc/pressure/memory
systemctl is-active systemd-oomd
swapon --show

统一层级正常的话通常会显示 cgroup2fs。如果系统没有 PSI 支持，或是完全无 swap 的紧张环境，内存压力上升速度会更快，systemd-oomd 大概率来不及按预期做出响应。

给低优先级服务接上压力处置策略

用 drop-in 配置修改一个可以被回收的服务，比如批处理类的服务 report-worker.service：

sudo systemctl edit report-worker.service

往里面写入下面的配置内容：

[Service]
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=55%
ManagedOOMMemoryPressureDurationSec=30s
ManagedOOMPreference=avoid

这里的 avoid 不是指这个服务永远不会被杀，只是降低它成为被杀候选的优先级。真正要重点保活的服务，可以保持默认的 auto，并且保证它不在配置为 kill 的父 cgroup 的可杀后代范围内。配置保存后重新加载配置、重启对应服务：

sudo systemctl daemon-reload
sudo systemctl restart report-worker.service
systemctl show report-worker.service \
  -p ManagedOOMMemoryPressure \
  -p ManagedOOMMemoryPressureLimit \
  -p ManagedOOMMemoryPressureDurationUSec

用 oomctl 验收监控对象，不要只盯着配置文件

配置写对了不代表 oomd 已经把这个服务纳入监控范围。先确认服务属性，再站在 oomd 的视角去核对实际监控状态：

systemctl show report-worker.service -p ControlGroup
sudo oomctl dump
sudo journalctl -u systemd-oomd --since "10 min ago"

oomctl dump 里可以直接看到被监控的 cgroup 列表和实时压力数据。日志里记录的候选路径、动作发生时间、服务状态要能完全对应上；如果只看到服务被重启，却找不到 oomd 相关的动作记录，要先排查是不是内核 OOM、服务自身异常退出或者其他 watchdog 触发的动作。

验收的时候建议留存三份核对依据：

误杀与回滚：把服务恢复到默认策略

如果低优先级判定不准确出现了误杀，先关闭服务级别的自定义策略，不要直接删掉整个 unit 文件。重新执行编辑 drop-in 的命令，把里面的 ManagedOOMMemoryPressure、阈值和偏好项全部删掉，然后执行：

sudo systemctl daemon-reload
sudo systemctl restart report-worker.service
systemctl revert report-worker.service

systemctl revert 会直接移除本地所有 drop-in 配置，适合确认完全不需要这组自定义配置的场景下使用。这个操作会删掉该服务的所有本地覆盖文件，执行前建议先用 systemctl cat report-worker.service 把当前配置做一份备份留存。

常见问题

systemd-oomd 会直接杀掉设置了 kill 属性的那个服务吗？

通常不会把设置属性的父 unit 当作第一目标，而是从符合条件的后代 cgroup 里挑选候选，最终的选中范围还受 cgroup 层级和候选资格规则影响。

没有 swap 还能使用 systemd-oomd 吗？

压力监控功能可能还能正常工作，但官方建议还是启用 swap；没有 swap 的场景下压力上升速度会非常快，systemd-oomd 很可能来不及按预期做出响应。

ManagedOOMMemoryPressure=auto 和 kill 有什么区别？

auto 不会主动把该 unit 纳入监控和处置对象；kill 才会让它参与 systemd-oomd 的压力策略规则，同时自动建立对 systemd-oomd 的依赖关系。

这套配置的价值根本不是“提前杀进程”，而是把谁可以被牺牲、用什么压力证据触发、怎么确认动作来源全部写成可审计的服务级策略。可以先在批处理或者缓存类非核心服务上验证效果，没问题之后再逐步扩大适用范围。