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