systemd-oomd 是 systemd 提供的用户空间 oom 管理器，基于 cgroup 和进程行为动态评分，在内核 oom killer 前主动终止进程；需通过精准 cgroup 划分、合理设置 memorymax/oomscoreadjust 及调整压力阈值来避免误杀或不杀。
systemd-oomd 是 systemd 提供的用户空间 OOM（Out-of-Memory）管理器，它在内核 OOM Killer 触发前主动干预内存压力，目标是更智能、可配置地终止进程。但它确实存在“杀错”或“该杀不杀”的问题——常见于默认策略过于宽泛、进程分类不准、或与传统 oom_score_adj 冲突。以下基于实际运维经验，给出关键配置要点和调优逻辑。
理解 systemd-oomd 的决策逻辑
systemd-oomd 不依赖 /proc/$PID/oom_score_adj，而是基于 cgroup 层级结构 + 进程行为特征（如内存增长速率、是否为“桌面交互类”）动态评分。它只作用于属于 systemd 管理的 scope 或 slice 的进程（即通过 systemd-run、systemd services 启动，或被自动归入 user.slice/system.slice 的进程）。独立启动的进程（如直接 bash 中 ./app）默认落入 system.slice，但缺乏明确资源归属，容易被误判。
它默认启用三类策略：
- MemoryPressure：当 cgroup 内存压力持续高于阈值（默认 80%）且增长快时触发
- SwapFree：交换空间低于阈值（默认 10%）时参与决策
- WorkingSetSize：对“工作集”过大的进程倾向终止（避免只看 RSS）
防止杀错：精准划分 cgroup 并设置保护等级
核心原则：让关键进程处于有明确定义、可配置的 cgroup 中，并显式声明其重要性。
- 用 systemd-run --scope --scope-property=MemoryAccounting=true --scope-property=MemoryMax=2G myapp 启动应用，确保它被纳入独立 scope，便于监控和隔离
- 为关键服务（如数据库、消息队列）创建专用 slice：
sudo systemctl set-property mydb.service MemoryMax=4G CPUWeight=100 IOWeight=100
配合 OOMScoreAdjust=-900（仍需保留，作为双重保险） - 禁用对特定 slice 的 oomd 干预：
sudo systemctl set-property system.slice ManagedOOMMemPressureLimit=0
或更彻底：sudo systemctl set-property mycritical.slice ManagedOOM=false
解决“不杀”问题：调整触发灵敏度与权重
systemd-oomd 默认较保守，尤其在低内存但无 swap 的系统上可能迟迟不动作。可通过以下方式增强响应：
- 降低内存压力触发阈值（单位：百分比）：
sudo systemctl set-property user.slice ManagedOOMMemPressureLimit=50 - 缩短压力持续时间窗口（单位：秒）：
sudo systemctl set-property system.slice ManagedOOMMemPressureDurationSec=10 - 强制启用 swap 压力参与决策（即使 swap 很小）：
sudo systemctl set-property system.slice ManagedOOMSwapFreeLimit=5 - 查看当前生效策略：
systemctl show --property=ManagedOOM* system.slice
与传统 oom_score_adj 协同而非冲突
systemd-oomd 和内核 OOM Killer 是两套机制，可共存但需注意优先级关系：systemd-oomd 先行动；若它未终止足够内存，内核 OOM Killer 才会 fallback 触发。因此建议：
- 对必须保活的核心进程（如 sshd、dbus），仍设 OOMScoreAdjust=-1000 —— systemd-oomd 尊重该值，不会选中 -1000 的进程
- 对“重要但可牺牲”的中间件（如日志收集 agent），设 OOMScoreAdjust=-300，既降低被 systemd-oomd 选中的概率，又保留 fallback 给内核 OOM Killer 的余地
- 避免将普通进程设为 OOMScoreAdjust=0（默认值）就放任不管 —— 它在 systemd-oomd 眼里就是“无特殊标记”，最易被选中
systemd-oomd 不是黑盒，它的日志（journalctl -u systemd-oomd -f）会详细记录每次决策依据、候选进程列表及最终选择原因。调优必须从日志出发，而不是凭猜测改参数。不复杂但容易忽略。
