进程被OOM killer杀死即使oom_score_adj设为-1000，主因是该值仅对当前进程有效、不继承exec新程序，且OOM评分还取决于RSS/swap大小，cgroup v2下更优先触发memcg OOM而非全局OOM。
进程被 OOM killer 杀死，即使你已将 oom_score_adj 调低（比如设为 -1000），仍可能被选中 —— 这通常不是配置没生效，而是理解或操作上存在几个关键盲区。
确认 oom_score_adj 确实已写入且生效
Linux 中 oom_score_adj 是每个进程独立的值，只对当前进程及其后续 fork() 的子进程生效，不会继承给由 exec 启动的新程序。常见误区：
- 在 shell 中执行
echo -1000 > /proc/$PID/oom_score_adj后，该进程若随后exec替换自身（如启动 Python 解释器、Java VM 或 systemd service），新程序会重置oom_score_adj为默认值（通常是 0） - systemd 服务需显式配置：
OOMScoreAdjust=-1000，且必须放在[Service]段；仅修改运行时 proc 文件对 daemon 类服务无效 - 容器环境（如 Docker、Podman）中，宿主机看到的是容器 init 进程的 PID，但容器内进程的
/proc/PID/oom_score_adj受 cgroup v2 的memory.oom.group和memory.min/memory.low影响更大，单纯调低 adj 值作用有限
OOM killer 实际选择依据不止是 oom_score_adj
oom_score_adj 只是评分因子之一，最终得分还正比于进程实际使用的物理内存（RSS + Swap），即：
OOM score ≈ (rss + swap) × (oom_score_adj + 1000) / 2000
这意味着：
- 一个
oom_score_adj = -500的进程，若 RSS 是另一个oom_score_adj = 0进程的 3 倍以上，它仍更可能被杀 -
oom_score_adj = -1000理论上得分为 0（免疫），但前提是进程未触发内核 OOM 路径中的其他判定逻辑（如 cgroup 内存限制超限、memcg OOM 优先级更高） - 内核 4.6+ 默认启用
CONFIG_MMU和 cgroup v2 时，OOM 处理优先走 memcg 层，此时看的是memory.oom控制文件和 cgroup 的 memory.high / memory.max 设置，而非全局 OOM killer
检查是否真被全局 OOM killer 杀死
很多“OOM killed”日志其实来自 cgroup 层，并非传统意义上的内核全局 OOM。验证方法：
- 查
dmesg -T | grep -i "killed process"：若含cgroup:字样（如cgroup: memory limit exceeded），说明是 memcg 触发，应检查对应 cgroup 的 memory.max 或 systemd scope unit 的内存限制 - 检查进程所属 cgroup：
cat /proc/$PID/cgroup，定位到对应memory.max文件，读取其值（max表示无限制，数字表示字节数） - 若使用 systemd，运行
systemctl show --property=MemoryMax,MemoryLimit $SERVICE，确认未被隐式限制（例如DefaultLimitMEM=...在/etc/systemd/system.conf中设置了全局上限）
更可靠的防护方式（替代或补充 oom_score_adj）
单靠调低 oom_score_adj 不足以保命，尤其在资源紧张时。建议组合使用：
- 为关键进程设置 memory.min（cgroup v2）：保证其内存不被回收，例如
echo 512M > /sys/fs/cgroup/myapp/memory.min - 用 memory.high 设软限制：超限时触发内存回收，但不直接 OOM，更适合平滑控制
- 禁用 swap（
swapoff -a）或降低vm.swappiness：减少因 swap 使用导致的虚假内存压力误判 - 监控真实内存压力：
cat /proc/meminfo | grep -E "(MemAvailable|MemFree|SwapFree)"和cat /sys/fs/cgroup/*/memory.current，比单纯看 oom_score_adj 更反映风险源头
