OOM Killer基于/proc/PID/oom_score打分选择进程，分数越高越优先被杀；可调oom_score_adj（-1000免疫，+1000最优先）；容器中按cgroup内存限制计算分数；日志见dmesg中“Kill process”及Mem-Info快照；进程退出后内存释放存在延迟，受page cache、匿名页回收机制及cgroup统计延迟影响；应通过oom_score_adj调优、内存限制和MemAvailable监控降低误杀。
OOM Killer 是怎么选中进程的
linux 内核在内存彻底耗尽时不会直接 panic，而是启动 oom_killer 机制，主动杀掉一个或多个进程来释放内存。它不随机选择，而是基于每个进程的 oom_score（位于 /proc/PID/oom_score）打分，分数越高越可能被干掉。
- 分数计算主要看进程占用的 RSS 内存，但会按比例惩罚那些“吃得多、优先级低”的进程
-
oom_score_adj（范围 -1000 到 +1000）可手动干预：设为 -1000 表示该进程完全免疫，+1000 则最优先被杀 - root 启动的进程默认不享特权，
oom_score_adj仍为 0，照样可能被选中 - 容器环境里，cgroup 的 memory limit 会压缩可用内存上限，导致更早触发 OOM，且容器内进程的
oom_score是相对于 cgroup 边界计算的
系统日志里能看到哪些关键线索
OOM 触发后，内核会往 dmesg 和 /var/log/kern.log（或 journalctl -k）写入结构化信息，重点盯住三类内容：
- 开头有
Out of memory: Kill process，后面紧跟着被杀进程名、PID、UID 和占用页数 - 中间有
Mem-Info:快照，列出各内存域（DMA、Normal、HighMem）的空闲页、活跃/非活跃匿名页、文件页等，能帮你判断是缓存没回收干净，还是真的物理内存见底 - 结尾常带
page allocation failure，附带调用栈（如alloc_pages_current），说明哪个子系统（比如 ext4、net、kvm）在申请内存时卡住了
注意：syslog 可能因缓冲区满而丢掉早期 OOM 日志；建议用 dmesg -T 查看带时间戳的原始输出，别只信 rsyslog 转发后的记录。
为什么有时候 kill 了进程，内存还是没释放
这不是 OOM Killer 失效，而是进程退出后，其占用的内存未必立刻归还给系统：
- 如果进程持有大量 page cache（比如刚做完大文件读写），这些页面属于“可回收”，但内核可能暂未触发回写或释放
- 进程用了
mmap(MAP_ANONYMOUS)或brk分配的匿名页，kill 后会立即标记为可回收，但实际回收时机取决于lru_lock竞争和当前内存压力 - 容器场景下，cgroup v1 的 memory subsystem 存在延迟统计问题：进程死后，
memory.usage_in_bytes可能滞后几秒才下降；cgroup v2 改进明显，但需确认内核版本 ≥ 4.5 且已启用
验证方法：在 OOM 后立刻执行 free -h 和 cat /sys/fs/cgroup/memory/memory.usage_in_bytes（v1）或 cat /sys/fs/cgroup/memory.current（v2），对比变化节奏。
如何降低误杀关键服务的概率
不能靠禁用 OOM Killer（vm.oom_kill = 0 会导致 kernel panic），得用组合策略：
- 对数据库、消息队列等核心服务，在启动前设置
echo -999 > /proc/PID/oom_score_adj（需在 fork 后、exec 前设，或用 systemd 的OOMScoreAdjust=-999） - 限制单个服务最大内存用量，比依赖 OOM Killer 更可靠：systemd 用
MemoryLimit=，docker 用--memory，kubernetes 用resources.limits.memory - 避免全局
vm.swappiness=0：虽然它减少 swap 使用，但也抑制了内核对 file cache 的回收积极性，反而让 OOM 更易触发；建议保持默认值 60 或设为 1～10 - 监控要覆盖
/proc/meminfo中的MemAvailable（不是MemFree），它反映真正可用内存，包含可快速回收的 cache；低于阈值时提前告警，比等 OOM 更可控
OOM 的本质是资源配额与使用节奏错配，日志只是结果，真正要调的是内存预算、回收策略和进程韧性设计。