引言

当系统内存压力达到极限，内核回收机制仍无法满足分配请求时，Linux内核将触发最后一道防线——OOM Killer（Out-of-Memory Killer）。它是内核中最为"暴力"的子系统，却也是保障系统在极端内存压力下仍能运转的最后手段。深入理解OOM Killer的评分机制、触发条件和调优方法，对于生产环境运维和系统级开发至关重要。

一、OOM Killer的触发机制

OOM Killer的触发是一个层层递进的过程，理解其触发链路是掌握OOM调试的前提：

1.1 从分配请求到OOM触发

当进程调用kmalloc()、vmalloc()或用户态调用malloc()触发缺页异常时，内核首先尝试通过Kswapd进行异步页面回收。如果回收后仍无法满足需求，则进入直接回收路径（Direct Reclaim）：

alloc_pages()
  └── alloc_pages_slowpath()
        └── out_of_memory()    // 核心入口
              └── select_bad_process()  // 选择牺牲进程
                    └── oom_kill_process()  // 执行杀戮

关键判断条件：当GFP分配标志包含__GFP_DIRECT_RECLAIM且所有回收尝试失败、总可用内存低于min水位线时，out_of_memory()才会被调用。

1.2 OOM的判定层级

OMS killer实际上在多个层级都可能被触发：

• 节点级OOM：NUMA系统中某节点空闲内存耗尽，触发__alloc_pages_may_oom()
• cgroup级OOM：内存控制组（memcg）使用量达到限制，触发mem_cgroup_oom()
• 全局OOM：整体系统内存耗尽，这是最常见的OOM场景

二、OOM Score评分算法剖析

OOM Killer的核心问题是：在多进程的系统中，选择哪个进程作为牺牲者？评分算法直接决定了被杀进程的选择。

2.1 评分计算公式

内核源码mm/oom_kill.c中的oom_badness()函数定义了评分规则：

unsigned long oom_badness(struct task_struct *p, unsigned long totalpages)
{
    long points;
    
    // 基础分数 = 物理内存占用百分比 × 1000
    points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) 
           + mm_pgtables_bytes(p->mm) / PAGE_SIZE;
    points = points * 1000 / totalpages;
    
    // 应用oom_score_adj调整
    points *= (long)oom_score_adj * 2;
    points /= (OOM_ADJUST_MAX - OOM_SCORE_ADJ_MIN + 1);
    
    // 特殊豁免：init进程、内核线程不参与评分
    if (is_global_init(p) || p->flags & PF_KTHREAD)
        return 0;
    
    return points;
}

评分结果存储在/proc/<pid>/oom_score中，范围0-1000+，分数越高越容易被选中。记住：oom_score = 物理内存占用比例 × 1000 × oom_score_adj因子。

2.2 oom_score_adj详解

oom_score_adj是用户可控的关键参数，取值范围-1000到+1000（早期版本为-17到+15，对应oom_adj已废弃）：

值	含义	典型应用
-1000	完全免疫OOM	systemd-udevd、关键守护进程
-500到-1	优先保护	数据库服务、缓存服务
0	使用默认评分	大多数普通进程
+1到+500	较高被杀风险	批处理任务、数据处理脚本
+501到+1000	最高被杀风险	实验性任务、临时进程

查看和调整方法：

$ cat /proc/1234/oom_score_adj
0
$ echo -800 | sudo tee /proc/1234/oom_score_adj
# 注意：负值需要CAP_SYS_RESOURCE权限

三、OOM Killer的Cgroup扩展

在容器化环境中，OOM Killer的表现与单机系统有显著不同，cgroup引入了额外的OOM语义层。

3.1 Memcg OOM与全局OOM的优先级

当进程的内存使用超出cgroup限制时，有两种触发路径：

• 默认行为：触发cgroup级OOM——只杀死该cgroup内的进程
• oom.group=1：配置cgroup组级OOM——杀死整个cgroup组的所有进程

3.2 Cgroup v2的内存控制器行为

cgroup v2简化了OOM语义，memory.max和memory.high的行为更加确定的：

# cgroup v2设置内存限制
echo "1G" > /sys/fs/cgroup/workload/memory.max
echo "800M" > /sys/fs/cgroup/workload/memory.high  # 开始限流

# 监控OOM事件
cat /sys/fs/cgroup/workload/memory.events
# oom 0
# oom_kill 0

四、OOM事件的监控与诊断

OOM事件在dmesg中留下完整的诊断痕迹，是事后分析的黄金数据源。

4.1 OOM日志格式解读

[12345.678] Out of memory: Killed process 1234 (java)
    total-vm:536870912kB, anon-rss:268435456kB, file-rss:0kB, 
    shmem-rss:0kB, 
    pgtables:1048576kB, oom_score_adj:0

关键字段说明：

• total-vm：进程虚拟地址空间总量
• anon-rss：匿名页RSS（堆、栈）—— 通常是内存大户
• file-rss：文件映射页RSS —— 容易被回收，风险较低
• pgtables：页表开销 —— 大量mmap时可能很高
• oom_score_adj：影响评分的调整值

4.2 监控工具链

全方位OOM监控需要多工具协作：

$ dmesg -T | grep -i "oom\|out of memory\|killed process"

# 实时监控所有进程的OOM分数
$ for pid in $(ls /proc | grep -E '^[0-9]+$'); do
    if [ -f /proc/$pid/oom_score ]; then
        echo "$(cat /proc/$pid/cmdline | tr '\0' ' ') \
              score=$(cat /proc/$pid/oom_score) \
              adj=$(cat /proc/$pid/oom_score_adj 2>/dev/null)"
    fi
  done | sort -t= -k2 -rn | head -20

# 使用systemd-cgtop查看cgroup内存压力
$ systemd-cgtop --batch -n 1

五、OOM Killer调优策略

有效的OOM管理不只是"不要杀我的进程"，而是构建层级化的内存保护体系。

5.1 sysctl内核参数调优

# 全局OOM策略控制
# 0=默认：允许杀进程；1=禁止OOM panic
vm.overcommit_memory = 2          # 禁止过度分配
vm.overcommit_ratio = 80          # 允许分配物理内存的80%

# cgroup v1 OOM控制
vm.panic_on_oom = 0              # OOM时不panic，而是杀进程

# OOM时是否dump core
vm.oom_dump_tasks = 1            # OOM时打印所有任务信息，便于诊断

vm.overcommit_memory三个值的行为差异：

• 0（默认启发式）：允许适度的overcommit，会检查明显的超大请求
• 1（总是允许）：永远不拒绝分配请求，适合确定性内存使用的场景
• 2（禁止过度分配）：总可分配量 = swap + (物理内存 × overcommit_ratio%)

5.2 应用层面的OOM防护

在systemd服务中通过内置指令实现OOM保护：

[Service]
MemoryMax=1G                       # 硬限制
MemoryHigh=800M                    # 软限制（开始限流）
OOMScoreAdjust=-500                # 降低OOM风险

对于传统init脚本，使用prctl或调整工具：

$ prctl --pid <pid> --set-oom-score-adj -500
# 或使用Python
python3 -c "syscall(SYS_prctl, PR_SET_NAME, b'service')" 

5.3 内存预压测试

生产部署前应进行内存压力测试，模拟OOM场景验证防护策略：

# 触发测试（危险操作，仅在测试环境）
echo f > /proc/sysrq-trigger      # 手动触发OOM Killer

# 使用stress-ng模拟
stress-ng --vm 4 --vm-bytes 512M --vm-keep --timeout 60s

六、与其他OOM机制的交互

OOM Killer不是孤立工作的，它与内核其他子系统紧密交互：

6.1 与Cgroup压力信息（PSI）的协同

现代内核中，PSI（Pressure Stall Information）在OOM发生前就能提供早期预警：

$ cat /proc/pressure/memory
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

• some：至少一个任务因内存压力被阻塞的比例
• full：所有任务同时因内存压力的比例——接近OOM

6.2 与Kswapd的协作

Kswapd率先在后台进行页面回收，OOM Killer只在Kswapd无法有效释放内存时才介入。这种分层设计大多数时候能在OOM发生前缓解内存压力，但过度碎片化或不可回收页（如内核分配、mlock）可能绕过Kswapd直达OOM。

七、实战案例与排错指南

案例1：Redis服务器频繁OOM死亡

某Redis实例（8GB RSS）被杀后，查看其oom_score_adj为0，导致评分极高。解决方案：

$ echo -600 > /proc/$(pidof redis-server)/oom_score_adj
# 或永久化
$ systemctl set-property redis.service OOMScoreAdjust=-600

案例2：容器内OOM但未触发宿主机OOM

容器内存限制为4GB，内部Java进程堆配置为3GB，加上堆外内存超过4GB触发cgroup OOM，外部宿主机完全无感知。关键命令：

$ journalctl -k | grep -i "memory cgroup"
$ cat /sys/fs/cgroup/<container-id>/memory.events
# oom 3      # cgroup已发生3次OOM

案例3：overcommit导致MySQL间歇性OOM

系统配置overcommit_memory=1，MySQL短期内大量分配致OOM，

$ sysctl -w vm.overcommit_memory=2
$ sysctl -w vm.overcommit_ratio=85

总结

OOM Killer是内核内存管理中最后也是最决绝的防御手段。理解其工作机制：

• 基础层：懂评分算法（oom_score = 内存占比 × 调整因子），才能理解进程的OOM风险优先级
• 工具层：熟悉/proc/<pid>/oom_score、PSI、dmesg日志等诊断工具链
• 系统层：掌握overcommit_memory、OOMScoreAdjust、cgroup mem.max等策略参数
• 实践层：建立预警（PSI）、分级保护（oom_score_adj）、预压测试的三层防御

期望通过本文的深度剖析，读者不仅能理解OOM Killer的内部算法，更能建立起从监控到防护的完整知识体系。