Linux OOM Killer：深入理解与实战指南

目录#

1. Linux 内存管理基础
2. OOM 条件与 OOM Killer 作用
3. OOM Killer 的工作原理
   • 3.1 内存过度提交（Overcommit）与 OOM 触发
   • 3.2 OOM 评分机制：oom_score 与 oom_score_adj
   • 3.3 进程选择算法
4. OOM Killer 激活的迹象与日志分析
5. OOM Killer 实战：常用操作与配置
   • 5.1 查看进程 OOM 相关参数
   • 5.2 调整进程 OOM 优先级（oom_score_adj）
   • 5.3 配置内存过度提交策略
6. 避免 OOM 与优化最佳实践
   • 6.1 合理规划内存与交换分区
   • 6.2 限制进程内存使用（cgroups）
   • 6.3 保护关键进程
   • 6.4 监控与告警
7. OOM 问题 Troubleshooting 流程
8. 参考资料

1. Linux 内存管理基础#

在深入 OOM Killer 之前，需先理解 Linux 内存管理的核心概念：

1.1 物理内存与虚拟内存#

• 物理内存（RAM）：实际硬件提供的内存，速度快但容量有限。
• 虚拟内存：内核通过 MMU（内存管理单元）将进程的虚拟地址映射到物理内存，允许进程使用超过物理内存的“逻辑内存”（通过交换分区实现）。

1.2 交换分区（Swap）#

当物理内存不足时，内核会将部分不活跃的内存数据（如闲置进程的内存页）写入磁盘上的交换分区（Swap Partition） 或交换文件（Swap File），释放物理内存供活跃进程使用。交换分区的速度远低于物理内存，过度依赖会导致系统卡顿（“swap thrashing”）。

1.3 内存过度提交（Memory Overcommitment）#

Linux 默认允许进程“过度申请”内存（即申请的内存总量超过物理内存 + 交换分区），这称为内存过度提交。内核通过 /proc/sys/vm/overcommit_memory 控制过度提交策略：

过度提交的好处是提高内存利用率（避免内存闲置），但风险是当进程实际使用内存超过物理内存 + 交换分区时，会触发 OOM。

2. OOM 条件与 OOM Killer 作用#

2.1 OOM 触发条件#

当进程申请内存时，内核经过以下步骤后仍无法满足需求，会触发 OOM：

1. 尝试分配物理内存；
2. 物理内存不足时，尝试回收缓存（如 page cache、slab cache）；
3. 回收缓存后仍不足，尝试将不活跃内存页交换到磁盘；
4. 交换分区也用尽，且无法进一步回收内存时，触发 OOM 条件。

2.2 OOM Killer 的角色#

OOM 发生时，系统已无可用内存，此时 OOM Killer 会介入，终止部分进程以释放内存，避免系统完全崩溃。它是内核的“最后手段”，目标是选择“对系统影响最小”的进程杀死。

3. OOM Killer 的工作原理#

3.1 内存过度提交与 OOM 触发#

OOM 通常与内存过度提交直接相关。例如：系统物理内存 4GB，交换分区 2GB，总可用内存 6GB。若进程 A 申请 5GB 内存（实际使用 3GB），进程 B 申请 4GB 内存（实际使用 3GB），总申请 9GB（过度提交），但实际使用 6GB（未触发 OOM）。若两进程后续均尝试使用全部申请内存（共 9GB），超过 6GB 总容量，则触发 OOM。

3.2 OOM 评分机制：oom_score 与 oom_score_adj#

OOM Killer 选择进程的核心依据是OOM 评分（oom_score），评分越高的进程越可能被杀死。评分由内核根据进程属性动态计算，用户可通过 oom_score_adj 手动调整优先级。

3.2.1 oom_score：动态评分#

oom_score 保存在 /proc/<pid>/oom_score，取值范围为 0~1000，值越高越易被杀死。内核计算逻辑如下：

[ \text{oom_score} = \left( \frac{\text{进程使用的物理内存}}{\text{系统总物理内存}} \right) \times 1000 + \text{其他因子（如进程运行时间、是否为特权进程等）} ]

例如：系统总物理内存 4GB，进程 A 使用 2GB，其 oom_score 约为 ( (2/4) \times 1000 = 500 )。

3.2.2 oom_score_adj：手动调整优先级#

用户可通过 /proc/<pid>/oom_score_adj 调整进程的 OOM 优先级，取值范围为 -1000~1000：

• -1000：进程永远不会被 OOM Killer 杀死（除非设置了 panic_on_oom，导致系统直接崩溃）。
• 0：默认值，由内核自动计算 oom_score。
• 1000：进程优先级最低，一旦 OOM 必被杀死。

oom_score_adj 直接叠加到 oom_score 中（实际计算更复杂，可参考 内核文档）。

3.3 进程选择算法#

OOM Killer 选择进程的步骤：

1. 扫描所有进程，排除内核线程、oom_score_adj = -1000 的进程。
2. 计算每个进程的 oom_score。
3. 选择评分最高的进程，发送 SIGKILL 信号终止。
4. 释放该进程的内存，若内存仍不足，重复步骤 1~3（可能杀死多个进程）。

3. OOM Killer 激活的迹象与日志分析#

当 OOM Killer 被触发时，内核会在日志中记录详细信息，可通过以下方式查看：

3.1 查看 OOM 日志#

3.1.1 dmesg 命令#

dmesg | grep -i "out of memory"

3.1.2 系统日志文件#

• Debian/Ubuntu：/var/log/kern.log
• CentOS/RHEL：/var/log/messages

3.1.3 日志示例与解读#

[12345.678901] Out of memory: Killed process 1234 (java) total-vm:8192000kB, anon-rss:4096000kB, file-rss:0kB, shmem-rss:0kB

• Killed process 1234 (java)：被杀死的进程 PID 为 1234，名称为 java。
• total-vm：进程申请的虚拟内存总量（8GB）。
• anon-rss：进程使用的匿名内存（未映射到文件的内存，如堆内存，4GB）—— 这是 OOM 评分的核心依据。
• file-rss：进程使用的文件映射内存（如代码段，可被重新读取，优先级较低）。

4. OOM Killer 实战：常用操作与配置#

4.1 查看进程 OOM 相关参数#

4.1.1 查看进程 oom_score#

# 查看 PID 为 1234 的进程 oom_score
cat /proc/1234/oom_score

4.1.2 查看进程 oom_score_adj#

cat /proc/1234/oom_score_adj

4.2 调整进程 OOM 优先级（oom_score_adj）#

4.2.1 保护关键进程（如 SSH 服务）#

将关键进程的 oom_score_adj 设置为 -1000，使其永不被 OOM Killer 杀死：

# 临时生效（重启进程后失效）
echo -1000 > /proc/$(pidof sshd)/oom_score_adj
 
# 永久生效（以 systemd 服务为例）
# 在服务配置文件（如 /etc/systemd/system/sshd.service）中添加：
[Service]
OOMScoreAdjust=-1000

4.2.2 降低非关键进程优先级#

将低优先级进程（如测试程序）的 oom_score_adj 设置为 1000，使其优先被杀死：

echo 1000 > /proc/$(pidof test-program)/oom_score_adj

4.3 配置内存过度提交策略#

通过调整 /proc/sys/vm/overcommit_memory 减少 OOM 风险：

4.3.1 临时修改#

# 设置为 2（从不过度提交）
sysctl vm.overcommit_memory=2
 
# 调整 overcommit_ratio（默认为 50，即物理内存的 50%）
sysctl vm.overcommit_ratio=75  # 允许申请内存 = 物理内存 * 75% + 交换分区

4.3.2 永久修改#

编辑 /etc/sysctl.conf，添加：

vm.overcommit_memory=2
vm.overcommit_ratio=75

生效：sysctl -p

5. 避免 OOM 与优化最佳实践#

5.1 合理规划内存与交换分区#

• 物理内存：根据业务需求配置足够的物理内存（如数据库服务器建议 16GB+）。
• 交换分区：
  • 普通服务器：建议大小为 物理内存的 1~2 倍（如 8GB RAM 配 16GB Swap）。
  • 大内存服务器（64GB+ RAM）：可配 8~16GB Swap（避免完全无 Swap，否则轻微内存波动即触发 OOM）。
  • 禁用 Swap：仅适用于严格低延迟场景（如实时系统），需确保物理内存绝对充足。

5.2 限制进程内存使用（cgroups）#

通过 cgroups（控制组） 限制进程的最大内存使用，避免单个进程耗尽系统内存。以 cgroups v2 为例：

# 创建控制组
mkdir -p /sys/fs/cgroup/myapp
 
# 限制内存使用不超过 2GB
echo 2G > /sys/fs/cgroup/myapp/memory.max
 
# 将进程 PID 加入控制组
echo <pid> > /sys/fs/cgroup/myapp/cgroup.procs

5.3 保护关键进程#

• 对核心服务（如数据库、Nginx、SSH）设置 oom_score_adj=-1000。
• 通过监控工具（如 Prometheus + Grafana）跟踪关键进程的内存增长趋势。

5.4 监控与告警#

实时监控内存指标，在 OOM 发生前预警：

• 关键指标：
  • 物理内存使用率（free -h）。
  • Swap 使用率（swapon -s）。
  • 内存申请失败次数（vmstat -s | grep "page allocation failures"）。
• 工具：top/htop（实时查看）、Prometheus + node-exporter（长期监控）、Zabbix（告警）。

6. OOM 问题 Troubleshooting 流程#

当 OOM 发生后，按以下步骤定位根因：

6.1 确认 OOM 事件#

通过日志确认 OOM 触发时间、被杀死的进程及内存使用情况：

grep -i "out of memory" /var/log/kern.log

6.2 分析内存使用趋势#

使用 sar（系统活动报告）查看 OOM 发生前的内存变化：

# 查看过去 3 天的内存使用（需预先安装 sysstat）
sar -r -f /var/log/sa/saXX  # XX 为日期（如 sa25 表示 25 日）

6.3 定位内存泄漏#

若 OOM 反复发生，可能存在内存泄漏：

• 工具：
  • top/htop：按内存使用率排序进程（M 键）。
  • pmap <pid>：查看进程内存映射（识别大内存区域）。
  • valgrind --leak-check=full ./program：调试用户态程序内存泄漏。
  • perf record -g -p <pid>：分析内核/用户态内存分配热点。

6.4 优化或扩容#

• 短期：限制问题进程内存、调整 OOM 优先级。
• 长期：修复内存泄漏、升级物理内存、优化应用架构（如分布式部署）。

7. 参考资料#

1. Linux 内核文档：OOM Killer
2. man 手册：proc(5)（/proc/sys/vm/* 相关参数）
3. Red Hat 文档：管理内存过度提交
4. cgroups v2 官方文档

结语#

OOM Killer 是 Linux 内存管理的“最后防线”，理解其工作原理并结合最佳实践（如合理规划内存、限制进程资源、保护关键服务），可显著降低 OOM 风险。当 OOM 发生时，通过日志分析和内存监控工具定位根因，是解决问题的关键。希望本文能帮助读者从“被动应对 OOM”转变为“主动预防 OOM”，提升系统稳定性。