当前位置:首页>Linux>第41天:OOM Killer:Linux内存溢出的审判者与守护者

第41天:OOM Killer:Linux内存溢出的审判者与守护者

  • 2026-10-08 23:58:52
第41天:OOM Killer:Linux内存溢出的审判者与守护者

谁动了我的进程?探秘Linux内核的内存法官

想象这样一个场景:你的嵌入式设备正在稳定运行,突然系统日志中涌现大量"Out of Memory"告警,某个关键进程被无情杀死,系统陷入半瘫痪状态——这就是OOM Killer在发挥作用。它就像Linux内核中的"法官",当物理内存耗尽时,必须做出艰难的决定:选择哪个进程为全局稳定性牺牲。

OOM Killer不是Linux的Bug,而是精心设计的保护机制。但这把"双刃剑"如何工作?何时触发?怎样调优?本篇文章将基于Linux 6.6内核源码,深入剖析这一内核核心组件的工作原理,帮助你在内存资源受限时做出明智的决策。


一、OOM Killer 概述

1.1 什么是OOM Killer

OOM Killer(Out of Memory Killer)是Linux内核的内存不足处理机制。当系统物理内存和交换空间(swap)都无法满足内存分配请求时,内核会触发OOM状态,选择并终止一个或多个进程以释放内存,保护系统整体稳定性。

核心问题:为什么不直接拒绝内存分配?

因为许多遗留应用和系统服务没有完善的内存分配错误处理,一旦内存分配失败可能导致不可预知的行为。杀死进程虽然"暴力",但能确保系统整体存活。

1.2 OOM Killer 的触发条件

OOM Killer的触发源于内存分配失败,通常发生在以下流程中:

  1. 内存分配请求失败
    :__alloc_pages_slowpath 无法获得可用内存
  2. 页面回收失败
    :页面回收和交换机制无法释放足够内存
  3. 触发OOM处理
    :调用 out_of_memory() 函数

二、OOM Killer 的评分机制

2.1 oom_score_adj 的工作原理

Linux使用 oom_score_adj 作为评分调整因子,配合 oom_badness() 函数计算进程的综合评分,选择分数最高的进程作为牺牲者。

/* 定义在 uapi/linux/oom.h */#define OOM_SCORE_ADJ_MIN       (-1000)#define OOM_SCORE_ADJ_MAX       1000

评分范围和含义:

oom_score_adj值
含义
-1000
完全禁止被OOM杀死(OOM_SCORE_ADJ_MIN)
-500 ~ -1
降低被选中的概率
0
默认值,无调整
1 ~ 999
增加被选中的概率
1000
优先被杀死(OOM_SCORE_ADJ_MAX)

2.2 oom_badness 函数:评分计算核心

这是Linux 6.6内核 mm/oom_kill.c 中的真实实现:

longoom_badness(struct task_struct *p, unsignedlong totalpages){    long points;    long adj;    /* 检查是否为不可杀死的进程(init或内核线程) */    if (oom_unkillable_task(p))        return LONG_MIN;    p = find_lock_task_mm(p);    if (!p)        return LONG_MIN;    /* 基线分数:RSS + 交换页 + 页表占用 */    points = get_mm_rss(p->mm) +             get_mm_counter(p->mm, MM_SWAPENTS) +             mm_pgtables_bytes(p->mm) / PAGE_SIZE;    /* 获取oom_score_adj调整值 */    adj = p->signal->oom_score_adj;    if (adj == OOM_SCORE_ADJ_MIN) {        task_unlock(p);        return LONG_MIN;    }    /* 应用调整值 */    adj *= totalpages / 1000;    points += adj;    task_unlock(p);    /* 确保分数为正 */    return points > 0 ? points : 1;}

评分公式总结:

最终分数 = (RSS + 交换页 + 页表页数) + (oom_score_adj × 总页数 / 1000)

2.3 查看和修改 oom_score_adj

# 查看特定进程的 oom_score_adjcat /proc/<pid>/oom_score_adj# 查看 oom_score(内核计算出的最终评分)cat /proc/<pid>/oom_score# 查看 oom_adj(旧接口,已被 oom_score_adj 替代)cat /proc/<pid>/oom_adj# 修改 oom_score_adj(需要root权限)echo -500 > /proc/<pid>/oom_score_adj# 为所有 nginx worker 设置保护for pid in $(pgrep nginx); do    echo -300 > /proc/$pid/oom_score_adjdone

三、OOM Killer 的工作流程

3.1 oom_evaluate_task:评估单个任务

staticintoom_evaluate_task(struct task_struct *task, void *arg){    struct oom_control *oc = arg;    struct task_struct *p;    unsigned long points = 0;    /* 检查是否可杀死 */    if (oom_unkillable_task(task))        goto next;    /* 检查cpuset/mempolicy约束 */    if (!oom_cpuset_eligible(task, oc))        goto next;    /* 如果是触发OOM的任务,优先级最高 */    if (task->mm == oc->mm) {        oc->chosen = task;        return 1; /* 直接返回,优先选择触发者 */    }    /* 计算评分 */    points = oom_badness(task, oc->totalpages);    /* 记录最高分值的进程 */    if (points > oc->chosen_points) {        get_task_struct(task);        put_task_struct(oc->chosen);        oc->chosen = task;        oc->chosen_points = points;    }next:    return 0; /* 继续评估下一个任务 */}

3.2 select_bad_process:选择要杀死的进程

static void select_bad_process(struct oom_control *oc){    oc->chosen = NULL;    oc->chosen_points = 0;    /* 如果是memcg OOM,只扫描该cgroup内的任务 */    if (oc->memcg) {        mem_cgroup_scan_tasks(oc->memcg, oom_evaluate_task, oc);    } else {        /* 扫描系统所有进程 */        for_each_process(p) {            oom_evaluate_task(p, oc);        }    }}

3.3 out_of_memory:OOM主处理函数

bool out_of_memory(struct oom_control *oc){    bool killed = false;    bool sysctl_panic_on_oom;    /* 步骤1:检查OOM killer是否被禁用 */    if (oom_killer_disabled) {        oom_killer_disabled = false;        return false;    }    /* 步骤2:通知OOM通知链,看是否有内存可回收 */    if (blocking_notifier_call_chain(&oom_notify_list, 0, oc)        == NOTIFY_OK) {        return true; /* 有内存被释放 */    }    /* 步骤3:检查当前进程是否即将退出 */    if (fatal_signal_pending(current)) {        set_thread_flag(TIF_MEMDIE);        return true;    }    /* 步骤4:检查panic_on_oom配置 */    sysctl_panic_on_oom = sysctl_panic_on_oom;    if (sysctl_panic_on_oom > 0) {        panic("Out of memory: %s mode",              sysctl_panic_on_oom == 2 ? "compulsory" : "normal");    }    /* 步骤5:检查是否直接杀死触发OOM的任务 */    if (sysctl_oom_kill_allocating_task) {        mark_oom_victim(current);        set_thread_flag(TIF_MEMDIE);        do_send_sig_info(SIGKILL, SEND_SIG_PRIV, current, PIDTYPE_PID);        return true;    }    /* 步骤6:选择要杀死的进程 */    select_bad_process(oc);    if (!oc->chosen) {        panic("Out of memory and no killable processes...\n");    }    /* 步骤7:杀死选定的进程 */    oom_kill_process(oc);    killed = true;    return killed;}

3.4 完整流程图

内存分配请求失败    ↓__alloc_pages_slowpath    ↓页面回收(kswapd)    ↓回收失败    ↓out_of_memory()    ↓├─ 检查OOM是否被禁用├─ OOM通知链├─ 检查当前进程是否即将退出├─ panic_on_oom 检查├─ oom_kill_allocating_task 检查└─ select_bad_process() → oom_evaluate_task() → oom_badness()    ↓oom_kill_process()    ↓发送 SIGKILL 信号    ↓OOM Reaper 异步收割内存    ↓系统恢复

四、OOM Reaper:异步内存收割机制

Linux 6.6包含OOM Reaper机制,专门用于解决OOM时的死锁问题:

/* OOM收割器核心逻辑 */staticvoidoom_reap_task(struct task_struct *tsk){    /* 延迟2秒后开始收割(OOM_REAPER_DELAY) */    if (!wait_for_completion_timeout(&tsk->signal->oom_reaper_completion,                                     msecs_to_jiffies(2000))) {        /* 进程未及时退出,开始收割 */        struct mm_struct *mm = tsk->signal->oom_reaper_mm;        if (mm) {            /* 优先回收匿名页,避免与正常退出流程冲突 */            oom_reap_task_mm(tsk, mm);        }    }}

OOM Reaper的好处:

  • 异步回收,避免死锁
  • 快速释放内存,恢复系统
  • 不依赖进程的退出清理流程

五、OOM Killer 配置与调优

5.1 真实存在的 sysctl 参数

# /proc/sys/vm/ 下的真实OOM相关参数# 1. panic_on_oom:OOM时是否panic# 0 = 不panic(默认)# 1 = 全局OOM时panic# 2 = 始终panicecho 0 > /proc/sys/vm/panic_on_oom# 2. oom_kill_allocating_task:是否直接杀死触发OOM的任务echo 0 > /proc/sys/vm/oom_kill_allocating_task# 3. oom_dump_tasks:OOM时是否打印所有任务状态echo 1 > /proc/sys/vm/oom_dump_tasks

5.2 持久化配置(sysctl.conf)

# /etc/sysctl.conf# 禁用panic_on_oom,避免系统直接崩溃vm.panic_on_oom = 0# 不直接杀死触发OOM的任务,让评分机制选择vm.oom_kill_allocating_task = 0# OOM时打印任务状态,便于调试vm.oom_dump_tasks = 1

5.3 systemd 服务配置

# 关键服务配置(如 sshd、systemd-journald)[Service]OOMScoreAdjust=-1000

5.4 嵌入式场景的优化建议

#!/bin/bash# oom_tune.sh - 嵌入式系统OOM优化脚本# 保护关键系统进程PROTECT_PIDS=(    "sshd"    "systemd"    "systemd-journald"    "rsyslogd")for name in "${PROTECT_PIDS[@]}"; do    pids=$(pgrep "$name")    for pid in $pids; do        echo -500 > /proc/$pid/oom_score_adj 2>/dev/null && \        echo "Protected $name (PID $pid)"    donedone# 降低应用进程优先级for pid in $(pgrep "myapp"); do    echo 500 > /proc/$pid/oom_score_adj 2>/dev/null && \    echo "Lowered priority for myapp (PID $pid)"doneecho "OOM tuning complete"

六、OOM Killer 监控与诊断

6.1 查看OOM日志

# 方法1:使用 dmesgdmesg | grep -i "oom\|killed"# 方法2:使用 journalctljournalctl -k --grep="oom\|killed"# 方法3:实时监控dmesg -w | grep -i "oom\|killed"

6.2 典型OOM日志解读

[12345.678901] Out of memory: Killed process 1234 (myapp) total-vm:1024000kB, anon-rss:512000kB, file-rss:0kB, shmem-rss:0kB

字段解析:

  • total-vm : 虚拟内存大小
  • anon-rss : 匿名内存大小(堆、栈)
  • file-rss : 文件映射内存大小
  • shmem-rss : 共享内存大小

6.3 监控当前系统状态

# 查看系统整体内存free -h# 查看每个进程的内存占用(按RSS排序)ps aux --sort=-rss | head -20# 查看系统OOM统计grep oom /proc/vmstat# 查看swappiness参数cat /proc/sys/vm/swappiness

七、代码实战:OOM安全编程

7.1 内存分配错误处理

#include<stdio.h>#include<stdlib.h>#include<string.h>/* OOM安全的内存分配函数 */void *oom_safe_malloc(size_t size){    void *ptr = malloc(size);    if (!ptr) {        fprintf(stderr, "[FATAL] Failed to allocate %zu bytes\n", size);        /* 这里可以执行清理操作后退出,而不是让OOM杀死 */        exit(EXIT_FAILURE);    }    return ptr;}/* OOM安全的realloc */void *oom_safe_realloc(void *ptr, size_t old_size, size_t new_size){    void *new_ptr = realloc(ptr, new_size);    if (!new_ptr && new_size > 0) {        fprintf(stderr, "[FATAL] realloc failed (old=%zu, new=%zu)\n",                old_size, new_size);        /* 保留原有内存,让调用者决定如何处理 */        return NULL;    }    return new_ptr;}intmain(void){    printf("=== OOM Safe Allocation Demo ===\n");    /* 分配100MB */    size_t size = 100 * 1024 * 1024;    char *buf = oom_safe_malloc(size);    if (buf) {        printf("Allocated %zu bytes\n", size);        /* 使用内存 */        memset(buf, 0xAA, size);        /* 尝试扩容 */        size_t new_size = 200 * 1024 * 1024;        char *new_buf = oom_safe_realloc(buf, size, new_size);        if (new_buf) {            printf("Reallocated to %zu bytes\n", new_size);            free(new_buf);        } else {            printf("Keeping original allocation\n");            free(buf);        }    }    printf("Demo complete\n");    return 0;}

7.2 监控系统内存压力

#include<stdio.h>#include<stdlib.h>/* 检查系统内存压力 */intcheck_memory_pressure(void){    FILE *fp = fopen("/proc/meminfo", "r");    if (!fp)        return -1;    long mem_total = 0, mem_available = 0;    char line[256];    while (fgets(line, sizeof(line), fp)) {        if (sscanf(line, "MemTotal: %ld kB", &mem_total) == 1)            continue;        if (sscanf(line, "MemAvailable: %ld kB", &mem_available) == 1)            continue;    }    fclose(fp);    if (mem_total == 0)        return -1;    /* 计算使用百分比 */    int used_percent = 100 - (int)((mem_available * 100) / mem_total);    return used_percent;}intmain(void){    int pressure = check_memory_pressure();    if (pressure >= 0) {        printf("Memory usage: %d%%\n", pressure);        if (pressure > 90) {            printf("[WARNING] Memory pressure is critical!\n");        }    }    return 0;}

八、常见问题与解决方案

8.1 问题:关键进程被OOM Killer杀死

解决方案:

# 1. 提高进程的OOM保护级别echo -500 > /proc/<pid>/oom_score_adj# 2. 使用systemd持久化配置# 编辑 /etc/systemd/system/<service>.service[Service]OOMScoreAdjust=-300

8.2 问题:系统频繁触发OOM

可能的原因:

  1. 应用程序存在内存泄漏
  2. 系统内存配置不合理
  3. 进程数量过多

解决步骤:

# 1. 检查是否有内存泄漏# 使用第40天学到的Kmemleak(内核态)或valgrind(用户态)# 2. 增加swap空间fallocate -l 2G /swapfilechmod 600 /swapfilemkswap /swapfileswapon /swapfile# 3. 使用cgroup限制进程内存mkdir /sys/fs/cgroup/memory/limitedecho 500M > /sys/fs/cgroup/memory/limited/memory.limit_in_bytesecho $pid > /sys/fs/cgroup/memory/limited/tasks

九、总结与最佳实践

9.1 核心要点回顾

方面
建议
监控
定期检查dmesg中的OOM日志
保护
关键服务使用负的 oom_score_adj
限制
非关键进程使用 cgroup 限制内存
编码
应用程序完善内存分配错误处理
配置
合理设置 panic_on_oom 参数

9.2 嵌入式系统特殊考量

  1. 资源受限:优先保护系统服务,应用进程可作为牺牲者
  2. 实时性:考虑使用 cgroup 内存隔离,避免应用影响系统
  3. 持久化:将OOM配置写入启动脚本,确保重启后生效
  4. 预分配:嵌入式应用考虑启动时预分配内存,避免运行时OOM

互动讨论话题

  1. OOM vs 拒绝分配:OOM Killer选择"杀死进程"而非"拒绝分配"的策略,这导致了遗留应用的兼容性,但也带来了难以预测的关键服务中断风险。在你的实际项目中,如果遇到内存不足场景,你更倾向于哪种策略?为什么?

  2. 嵌入式OOM经验:作为嵌入式开发者,你是否遇到过OOM导致的系统故障?当时是如何定位和解决的?欢迎分享你的宝贵经验!


如果觉得对你有帮助,请帮忙点赞,分享,谢谢~

往期精彩分享

✅️Linux 从 0 到 1 保姆级入门指南

✅️Linux通用技能

✅️ 工作经验分享

关注"linux探究"微信公众号,获取更多Linux技术干货与版本更新资讯

最新文章

随机文章