systemd-oomd 杀进程规则不生效或杀错进程的配置坑

systemd-oomd 默认不基于进程 RSS，而是依据 cgroup 内存压力（memory.pressure）和使用趋势触发，仅作用于启用 MemoryAccounting=yes 的服务或 scope 单元；需确认进程在受管 cgroup 下、配置正确、压力达阈值且排除误杀。

systemd-oomd 默认行为偏保守，规则不生效或误杀进程，通常不是 bug，而是配置未对齐其设计逻辑——它不直接看进程 内存占用，而是基于 cgroup 层级的内存压力（memory.pressure）和内存使用趋势（如 memory.current 增速），且只作用于启用了 MemoryAccounting=yes 的 scope 或 service 单元。

确认目标进程是否在受管 cgroup 下

systemd-oomd 只管理由 systemd 创建并启用内存统计的 cgroup，普通 fork 出的进程（如手动 bash 启动的程序、容器未配 memory controller）默认不受控。

• 检查进程所在 cgroup：运行 cat /proc//cgroup | grep memory，确认路径形如 /sys/fs/cgroup/memory/system.slice/myapp.service，而非 / 或 /user.slice/……（user session 默认不启用 MemoryAccounting）
• 确保服务单元启用内存统计：在 .service 文件中显式设置 MemoryAccounting=yes，并重载配置：systemctl daemon-reload && systemctl restart myapp.service
• 对临时进程，可用 systemd-run --scope -p MemoryAccounting=yes --scope your-command 手动纳入管控

理解 oomd 的触发条件不是“内存满”，而是“持续高压”

systemd-oomd 不基于绝对内存值（如 RSS > 80%），而是依赖内核提供的 memory.pressure（平均 10 秒 /60 秒 /300 秒的压力值）与 memory.current 趋势。若压力值未达阈值（默认 medium=5%, critical=10% 持续 10s），即使内存已近耗尽也不会触发。

• 查看实时压力：读取 /sys/fs/cgroup//memory.pressure，例如 some=0.5 avg10=0.2 avg60=0.1 avg300=0.05，只有 avg10 连续超阈值才可能触发
• oomd 日志在 journalctl -u systemd-oomd -f 中，关注 Pressure is high 和 Deciding to kill 行，而非只看“killed”结果
• 避免误判：短时 spike（如 GC、批量加载）可能不触发；而长稳态中等压力（如 avg10=7% 持续 20s）反而更易被选中

防止误杀关键进程：用 oomd.conf 精细控制优先级

oomd 默认按 cgroup 内存占比 + 启动时间加权打分，但可通过 /etc/systemd/oomd.conf 或 per-cgroup 配置文件 干预。常见误杀源于未排除系统关键服务或高内存但低压力的服务（如缓存进程）。

• 全局降低敏感度：在 [OOMDaemon] 下设 SwapUsedLimit=90%、MemoryAvailableLimit=10%（单位为内存总量百分比），避免过早介入
• 为特定 service 降权：在 /etc/systemd/system/myapp.service.d/oomd.conf 中添加：
  [Service]
  OOMScoreAdjust=-500
  （注意：这是 systemd 的 OOMScoreAdjust，影响 oomd 打分权重，值越低越不易被杀；-1000 完全豁免，但需谨慎）
• 完全屏蔽某 cgroup：创建 /etc/systemd/oomd.conf.d/90-ignore-db.conf，内容为：
  [Manager]
  IgnoreCGroupPaths=/system.slice/postgresql.service

验证与调试：别只信 top，要看 cgroup 视图

top、htop 显示的是进程 RSS，而 oomd 看的是 cgroup memory.current（含 page cache、swap cache 等）。同一进程在不同 cgroup 下表现可能差异巨大。

• 对比数据：运行 systemctl status myapp.service 查看“Memory:”行，再手动读取 cat /sys/fs/cgroup/system.slice/myapp.service/memory.current，两者应基本一致
• 模拟压力测试：用 stress-ng --vm 2 --vm-bytes 1G --timeout 60s 在指定 scope 下运行，配合 watch -n1 'cat /sys/fs/cgroup/*/memory.pressure' 观察响应
• 禁用 swap 干扰：若系统启用了 swap，oomd 可能延迟触发（因 memory.available 包含 swap 剩余），测试时可临时 swapoff -a 排查