Linux系统OOM Killer机制解析与实战处理

1. 当Linux系统遭遇OOM时的紧急处理

凌晨三点，服务器监控突然告警。登录系统一看，某关键进程已被OOM killer无情终结，业务陷入瘫痪。这种场景对于Linux运维人员来说绝不陌生。OOM（Out Of Memory）是Linux内核在系统内存耗尽时触发的保护机制，它会根据算法选择并终止占用内存最多的进程，以此释放内存保证系统继续运行。

新手遇到OOM时往往会手忙脚乱，要么盲目重启服务，要么胡乱调整参数。实际上，理解OOM的运行机制和应对策略，是每个Linux系统管理员必须掌握的生存技能。本文将带你深入OOM的底层原理，并提供一套完整的诊断、处理和预防方案。

重要提示：OOM killer的干预意味着系统内存管理已出现严重问题，不能仅停留在"杀掉进程就完事"的层面，必须追查根本原因。

1.1 OOM killer的工作机制

Linux内核在分配内存时，会检查系统的可用内存情况。当满足以下条件时，OOM killer就会被触发：

1. 物理内存和交换空间(swap)几乎耗尽
2. 内核无法通过缓存回收(cache reclaim)获得足够内存
3. 内存分配请求被连续拒绝

此时内核会计算每个进程的"坏分数"(badness score)，选择分数最高的进程终止。计算依据包括：

• 进程当前占用的内存量
• 进程运行时间长短
• 进程优先级(nice值)
• 是否为特权进程
• 是否直接与用户交互

bash复制# 查看系统是否曾经触发过OOM
dmesg | grep -i "killed process"

2. 现场诊断与应急处理

2.1 实时监控内存状态

当系统出现响应迟缓但尚未触发OOM时，应立即使用以下命令检查内存状态：

bash复制free -h              # 查看内存总量和使用情况
vmstat 1 5           # 监控内存、交换分区和IO状态
top -o %MEM          # 按内存占用排序进程
ps aux --sort=-%mem | head -10  # 显示内存占用前十的进程

重点关注以下指标：

• free命令中的available值（而非free值）
• vmstat中的si(swap in)