OOM管理机制

可视化演示

展示Linux OOM Killer的进程打分策略和内存监控预警，包含oom_score排名和内存使用趋势与OOM阈值线。

OOM触发机制

仓库的货架旁立着一块电子秤，上面显示的不是“剩余面积”而是“预估可用面积”——因为有些空间虽然空着，但旁边堆着随时可能倒下来的备用货架，不能算作真正可用。内核里这个读数叫 MemAvailable，它不只看空闲页，还会把“当下能立刻回收的页缓存”也算进去，同时扣掉一层“保命水位”（low watermark，内核为自己预留的最低水位线）。当这个读数归零，分配内存的请求又迟迟得不到满足，才轮到 OOM Killer 出场。

技术上的触发路径是这样的：进程申请内存时调用 __alloc_pages_nodemask，内核先去空闲链表找页，找不到就唤醒回收线程尝试压缩和回收，回收仍然颗粒无收，最终走进 out_of_memory() 分支。值得警惕的是 overcommit（超额承诺）：内核默认允许进程申请超过物理内存的虚拟空间，就像老板先开空头支票，等客户真的来提货时仓库才会暴露缺口。

当电子秤读数跌破预警，老周会先做两轮“温和处理”：扔纸箱、搬外棚。如果扔完搬完还是不够，他才去翻那本“优先丢弃清单”——OOM Killer 并不是一言不合就动手的暴脾气，而是穷尽所有常规手段后的最后裁决。

内存回收与OOM

老周的第一反应永远是“能回炉就回炉”：把干净的页缓存（读过的文件、程序镜像）直接扔掉，脏页写回磁盘后再扔，匿名页则整页搬到楼外临时棚（swap）。搬走的代价是时间——换入换出都要读写磁盘，像从外棚搬货回货架要花几趟人工一样。可有些货是焊死在货架上的：被内核锁定的页面（比如 mlock 锁定的内存）、内核核心代码驻留页，这些连老周也挪不动，称为“不可回收页面”。

如果可回收的纸箱已经扔光、外棚也堆满了，还是无法满足一个新订单，老周才走向那个放着红按钮的角落。内核的判断逻辑很直接：先按优先级遍历各个内存节点执行回收，回收数量不达标才执行 out_of_memory()。所谓“回收失败”，不一定是可回收内存为 0，也可能是回收速度跟不上分配速度，或者系统处于无法睡眠等待的原子分配上下文，根本等不起磁盘写回。

回收不是无限度的：内存压力越大，老周刷盘越频，系统越卡；外棚（swap）本身也有上限。当 reclaimable 趋于 0，而新的内存请求仍在排队，内核的“最后通牒”才会下达——启动 OOM Killer，进入下一个章节的残酷打分。

OOM打分策略

既然必须丢货，丢哪箱？老周掏出计算器，给每箱货物称重打分，分数最高的那箱就要被丢出去。称重公式非常朴素：看这箱货现在占了多少货架（RSS 常驻内存）、占了多少外棚（swap 用量）、以及它自己的“标牌”占多大（页表体积）。三者相加后除以仓库总容量，再放大一千倍，得到一个 0 到 1000 之间的“坏品评分”。

内核实现里这个函数叫 oom_badness()，分数越高代表“清掉它能释放的空间越多、对系统运行影响越小”。特权进程会被打一点折：拥有 CAP_SYS_ADMIN 能力的进程（多为 root 启动的系统服务）得分会减去四分之一，算是老周给“自己人”的一点情面，但只是轻描淡写地减分，绝不豁免。最终 select_bad_process() 遍历所有进程，挑出坏品评分最高者作为牺牲品。

打分看起来绝对公平，但“公平”未必等于“合你心意”。如果你的数据库进程恰好占内存最多，它就会在下一轮被选中。所以内核又给了一把“手动天平”——调整各进程的权重，让真正重要的货永远留在货架上。

oom_score_adj调节

什么叫“重要的货”？仓库里没有客观标准，只能靠人贴标签。/proc/<pid>/oom_score_adj 就是给每个进程贴的标签：取值范围是 -1000 到 1000 的整数。负号代表“尽量别扔我”，正数代表“清仓时优先扔我”。贴到 -1000 被称为 OOM_DISABLE，内核直接跳过该进程，即使全仓库只剩它一个活物也不碰它——这是真正的传家宝待遇。

最终判决分数就是坏品评分加上这张标签：

实际部署时，Nginx 这类反向代理一旦被杀，所有在线请求都会断，运维通常会把它设为 -500 甚至更低；而 Spark 的离线 Executor 这类“丢了可以重跑的活”，可以设为正值，让它在内存危机时优先出局。容器的场景也适用：容器内进程的 oom_score_adj 可以在 cgroup 维度统一设置，Kubernetes 里还会根据 QoS 等级自动赋予不同权重。标签贴得好，OOM 来临时损失的只是边缘服务，核心业务毫发无损。

监控预警方法

老周再会挑货，事后也得有账可查。Linux 把每次 OOM 判决都写进内核环形缓冲区，用一条命令就能翻出来：

典型日志长这样：

这段日志就是老周在记录本上写的判决书：谁被杀、它的虚拟内存和物理内存各占多少。除了翻旧账，还要看实时读数：/proc/<pid>/oom_score 显示每个进程的当前总分，/proc/<pid>/oom_score_adj 显示人工标签，/proc/meminfo 里的 MemAvailable 则是全仓库的“余量电子秤”。把这几项汇聚到监控系统，就能给爆仓装上倒计时警报：

预警之后做什么？先看 ps aux --sort=-rss 揪出内存大户，再顺着 oom_score_adj 检查关键服务有没有贴好“传家宝”标签。监控不是买保险，而是让“爆仓事件”从意外事故变成可预判、可演练的日常操作。

dmesg | grep -i oom

Out of memory: Killed process 1234 (python3) total-vm:4567890kB, anon-rss:123456kB, file-rss:890kB

内存规划调优

最好的 OOM 是永远不会发生的 OOM。要让它不发生，得从源头规划。第一件事是收紧老板的空头支票——/proc/sys/vm/overcommit_memory 设为 2（严格模式），内核会用下面这个公式算出“承诺上限”，超额的内存申请直接拒绝：

第二件事是 swap 和外棚规划：内存越大，swap 的价值越偏向“兜底”而非“扩容”，机械盘上的 swap 甚至会让系统卡到怀疑人生。第三件事是容器限额设计：给每个 Pod 设定 resources.limits.memory，等于给每个包间画好天花板，包间爆了自己清场，不连累整栋楼。最后，用 oom_score_adj 给数据库、网关这类“传家宝”贴上 -1000 的免死金牌。全套做下来，即使某天流量突变，你失去的也只是最不重要的那几箱货。

AI 应用场景

Python 演示

#!/usr/bin/env python3"""OOM Killer 选择过程模拟：按 badness 打分挑选"代价最小"的进程终止"""  class Proc:    def __init__(self, name, rss, swap, adj=0):        self.name = name        self.rss = rss        self.swap = swap        self.adj = adj     def mem(self):        return self.rss + self.swap     def badness(self, total):        return self.mem() * 1000 // total     def score(self, total):        return self.badness(total) + self.adj  TOTAL_MB = 6000MIN_FREE_MB = 512  def available_mb(procs):    used = sum(p.mem() for p in procs)    return TOTAL_MB - used  def oom_kill(procs):    victim = max(procs, key=lambda p: p.score(TOTAL_MB))    procs.remove(victim)    return victim  def main():    procs = [        Proc("java", 2800, 500, adj=-200),        Proc("mysql", 1800, 300, adj=0),        Proc("python", 600, 100, adj=300),        Proc("nginx", 150, 0, adj=-500),        Proc("redis", 700, 0, adj=-100),    ]    round_no = 0    while available_mb(procs) < MIN_FREE_MB and len(procs) > 1:        round_no += 1        victim = oom_kill(procs)        print("Round #%d: kill %s (score=%d, free %dMB)" % (            round_no, victim.name, victim.score(TOTAL_MB), victim.mem()))    print("Available: %dMB, survivors: %s" % (        available_mb(procs), ", ".join(p.name for p in procs)))  if __name__ == "__main__":    main()

1. def badness(self, total):实现 rss+swap 占总内存的比例并放大千倍，对应正文的坏品评分。
2. def score(self, total):把 badness 和人工标签 oom_score_adj 相加，得到最终判决分数。
3. victim = max(procs, key=lambda p: p.score(TOTAL_MB))内核 select_bad_process() 的简化版，挑出分数最高的进程。
4. procs.remove(victim)模拟 OOM Killer 终止进程，内存随之释放。
5. while available_mb(procs) < MIN_FREE_MB and len(procs) > 1:只要可用内存低于保命水位就一直“杀”，直到内存充裕或只剩一个进程。

常见误区

面试题