Linux 内存不足时 OOM Killer 的选择逻辑与 cgroup 限制下的行为差异-北京尧图网络

Linux 内存不足时 OOM Killer 的选择逻辑与 cgroup 限制下的行为差异1. 从一次线上被杀事件说起先看一个很常见的场景。某台 8 核 16GB 的服务器上跑着一个 Java 服务和一个日志处理进程。凌晨两点告警系统发出“服务不可用”登录机器一看Java 进程不见了dmesg里有一行Out of memory: Killed process 12345 (java)。运维第一反应往往是“内存泄漏了”于是加内存、重启问题暂时消失但几天后又出现。这里真正需要回答的是三个问题内存到底被谁用完了内核在什么时刻决定要杀进程为什么被杀的是 Java而不是旁边那个看起来更占内存的日志进程如果这台机器上还开启了 cgroup v2 限制比如给服务设置了memory.max那这次的凶案现场会完全不同进程可能不是被全局 OOM Killer 杀的而是被 cgroup 级别的 OOM 处理杀的日志位置、可见性、可干预手段都不一样。大部分讲 OOM 的资料一上来就抛出oom_score、badness、memory cgroup这些名词读者记不住也不清楚它们之间谁先谁后。这篇文章反过来先给一个能复述的整体流程再用具体的分数计算、内存统计和日志字段把它填满。读完你应当能独立完成一次 OOM 定位并知道全局 OOM 与 cgroup OOM 在选人逻辑上的关键差别。2. 一句话模型与全局框架先用一句话概括内存分配先尝试回收回收不动才触发 OOM触发后内核给每个候选进程算一个“可杀分数”分数最高的被杀而在 cgroup v2 里这个流程被压缩到某个控制组内部先杀组内、不一定杀全局最优。把整体过程拆成四个角色和一条主链路申请者发起malloc、mmap、page fault 的进程或内核路径它只是要内存不关心后果。回收者内核的页回收逻辑先丢可丢弃的页缓存再写回脏页必要时换出匿名页到 swap。上限全局物理内存加 swap 构成系统总上限cgroup v2 的memory.max构成某个控制组的上限。裁决者OOM Killer在回收失败后按打分选择牺牲者。一次内存申请完整的走向可以画成下面这样进程申请内存 | v 有空闲页? --是-- 直接分配结束 |否 v 触发直接回收 (direct reclaim) | -- 能回收出足够页? --是-- 分配成功进程短暂卡顿 | -- 回收失败 / 回收代价过高 | v 判断超限的是全局还是 cgroup | --------------------------- | | v v 全局 OOM cgroup v2 OOM 扫描全系统进程只扫描该 cgroup 内进程按 badness 打分按组内 badness 打分杀分最高者杀分最高者可能带上子组这张图里最容易被忽略的是“回收失败”这一步。很多人的直觉是“内存用到 100% 就杀进程”实际内核会先拼命回收包括丢掉文件页缓存、压缩内存、换出到 swap。只有当回收也救不回来或者回收本身已经让系统失去响应OOM Killer 才会出手。所以看到 OOM 日志之前通常已经经历了一段明显的卡顿和 swap 压力。3. 内存是怎么一步步被“逼到墙角”的3.1 物理内存的几块账理解 OOM 前要先知道内存都花在哪。用free -h看最直观$free-htotal usedfreeshared buff/cache available Mem: 15Gi9.6Gi 412Mi 380Mi5.8Gi5.1Gi Swap:2.0Gi1.7Gi 300Mi这块输出里used高不一定是坏事buff/cache是可以被回收的文件缓存。真正决定“还有多少余量”的是available。当available接近 0Swap又被用得差不多系统就进入了回收压力很大、随时可能 OOM 的状态。需要分清三种内存它们的回收难度依次上升内存类型典型来源是否容易回收回收代价文件页缓存读写文件、程序二进制容易低直接丢弃或延迟写回匿名页进程堆、栈、malloc 的内存困难高必须有 swap 才能换出内核内存slab、页表、网络缓冲视类型而定部分不可回收OOM 往往发生在匿名页过多、swap 又不足的场景。文件缓存再多内核也能丢掉匿名页没有 swap 就只能一直占着直到把系统推过临界点。3.2 回收压力从哪里看/proc/vmstat里有几个直接反映回收痛苦的计数器$grep-Epgscan|pgsteal|allocstall|pswpout|pswpin/proc/vmstat pgpgin48213pswpin1842pswpout92017pgscan_direct210934pgsteal_direct198233allocstall12041逐项读法如下。pgscan_direct是进程自己被迫进入直接回收时扫描的页数数值持续增长说明分配路径频繁被阻塞。pgsteal_direct是从中成功回收的页数。allocstall表示分配因为回收而停顿的次数这个值明显上涨基本等于“系统已经在挨打了”。pswpout是换出到 swap 的页数匿名页换出伴随磁盘 I/O会让延迟进一步恶化。当allocstall高、pswpout高、available低同时出现即使还没有 OOM 日志也应该主动介入而不是等它自己杀进程。3.3 swap 到底帮不帮忙swap 的作用是给匿名页一个临时去处从而延长系统存活时间。但它不是免费内存换出换入都要走磁盘。对延迟敏感的在线服务大量 swap 换入换出往往比直接 OOM 更难受请求延迟从几毫秒涨到几百毫秒还可能触发超时雪崩。这里有一个重要取舍完全不配 swap匿名页无法换出回收手段变少OOM 来得更快更干脆但延迟相对稳定。配少量 swap能吸收突发内存尖峰给运维争取响应时间但换出量大时数据库、JVM 这类进程延迟会明显抖动。常见的生产做法是给系统盘配 1 到 2 倍内存的 swap 只用于应急或者干脆关闭 swap 并把内存限制交给 cgroup 精确控制。4. OOM 打分内核怎么挑人4.1 badness 分数的组成OOM Killer 不是随机杀也不是简单杀“最大”的而是给每个进程算一个分数再乘上调整系数。简化后的逻辑是进程占用内存越多分数越高oom_score_adj可以人为加减分。核心公式可以近似理解为badness 与进程占用的内存规模正相关最终分数 f(badness) oom_score_adj 的影响进程内存占比越大、oom_score_adj 越高越容易被杀实际查看当前进程分数可以读/proc/pid/oom_score$cat/proc/$(pgrep-fjava.*app.jar|head-1)/oom_score834这个数字是内核当前算出来的打分范围大致在 0 到 1000。数字越大越危险。旁边还有/proc/pid/oom_score_adj范围是 -1000 到 1000用来在分数基础上做人工偏移。4.2 oom_score_adj 的方向容易搞反oom_score_adj的语义是“在最终分数上叠加多少”。因此设为正数提高被杀概率比如把可牺牲的批处理任务设为 500。设为负数降低被杀概率比如把数据库主进程设为 -800。设为 -1000等价于“尽量不杀”但不是绝对豁免系统完全无路可走时仍可能被杀。可以用下面这个完整示例验证效果。目标是在一台测试机上创建一个持续吃内存的进程并对比调整oom_score_adj前后的分数。前置条件是有一台允许 OOM 的测试机至少 4GB 内存并且你有 root 权限。# 示例一观察 oom_score 与 oom_score_adj 的关系# 创建一个持续申请匿名内存的进程python3-c import time buf [] for i in range(200000): buf.append(bytearray(1024 * 1024)) time.sleep(0.05) PID$!# 查看默认分数cat/proc/$PID/oom_scorecat/proc/$PID/oom_score_adj关键步骤说明进程占用内存增长后oom_score会随着它在系统内存中的占比上升而变大oom_score_adj默认是 0。接下来做一次调整把它变成“优先被杀”echo800/proc/$PID/oom_score_adjcat/proc/$PID/oom_scorecat/proc/$PID/oom_score_adj预期结果oom_score_adj变为 800oom_score明显抬高。如果再把oom_score_adj设为 -800分数应显著下降。容易改错的地方是权限非 root 进程只能把自己的oom_score_adj往高调、往低调的幅度也有限制跨进程修改通常需要 root。需要特别区分两个东西oom_score是只读的打分结果oom_score_adj是你可以写的调整量。很多人误以为改oom_score就能改变命运实际上改的是后者。4.3 systemd 场景下怎么设直接写/proc只在进程存活期间有效重启就没了。生产上更推荐用 systemd 单元固定下来。下面是一个完整的服务单元示例目标是把核心接口服务保护起来把可牺牲的离线任务标成优先被杀。# /etc/systemd/system/order-api.service [Unit] DescriptionOrder API Service Afternetwork.target [Service] Typesimple Userappuser ExecStart/usr/bin/java -Xmx2g -jar /opt/app/order-api.jar Restarton-failure RestartSec3 # 降低被杀概率最小值 -1000 OOMScoreAdjust-700 LimitNOFILE65535 [Install] WantedBymulti-user.target对应地给离线报表任务写一个相反倾向的单元# /etc/systemd/system/report-batch.service [Service] Typeoneshot ExecStart/opt/app/report.sh # 提高被杀概率允许被优先牺牲 OOMScoreAdjust600执行systemctl daemon-reload后重启服务systemctl show order-api -p OOMScoreAdjust可以确认值已经生效。这个配置的工程价值在于把“谁更重要”这件事从事故现场的临时判断变成部署阶段就固化的策略。适用场景是多服务混部边界是它只影响被打分的偏移不能阻止真正无路可走时的全局 OOM。5. cgroup v2 下 OOM 的边界被改了5.1 从全局到局部的关键切换在没有 cgroup 限制的机器上OOM Killer 面对的是全系统进程池。而在 cgroup v2 里每个控制组可以有独立的memory.max。当某个组的匿名内存加文件内存触到memory.max内核会优先在这个组内回收、组内 OOM而不是直接拉全局进程下水。这意味着两件事变了。第一被杀进程通常属于“触限的那个组”全局上可能还有很多空闲内存。第二如果组内没有可杀的进程或者组本身设了memory.oom.group行为可能升级为杀掉整组。把这两种路径并排看全局 OOM 路径系统 available 接近 0 | v 扫描所有进程 - 计算 badness - 杀全局最高分 cgroup v2 OOM 路径某个 cgroup 用量触及 memory.max | v 先在该组内回收 | v 回收失败则扫描该组内进程 - 杀组内最高分 | v 若设置 memory.oom.group1则整组一起杀对多租户或容器化环境这带来的直接好处是故障隔离一个失控的容器不会立刻拖垮整台宿主机。但坏处也明显某个容器反复被 cgroup OOM宿主机监控若只看全局内存会完全发现不了。5.2 memory.max 的读写法cgroup v2 统一挂载在/sys/fs/cgroup下。下面这段命令展示一个完整流程创建控制组、设置上限、观察 OOM 行为。前置环境是已启用 cgroup v2 的 Linux可用mount | grep cgroup2确认需要 root。# 示例二用 cgroup v2 限制一个进程的内存# 确认是 cgroup v2mount|grepcgroup2# 创建控制组mkdir-p/sys/fs/cgroup/demo# 设置内存上限 200MBecho200M/sys/fs/cgroup/demo/memory.max# 允许 swap 与内存合计 0即不允许用 swap按需调整echo0/sys/fs/cgroup/demo/memory.swap.max# 把当前 shell 放进该组echo$$/sys/fs/cgroup/demo/cgroup.procs# 在该组内启动一个吃内存的进程python3-c buf [] for i in range(1000): buf.append(bytearray(1024 * 1024)) 关键步骤说明写cgroup.procs会把整个 shell 及其后续子进程迁入该组因此后续启动的 Python 会受 200MB 限制。预期结果是进程在内存逼近上限后被组内 OOM 杀掉而不是拖垮整机。容易改错的地方有两处一是memory.max的值要写清楚单位200M和200含义完全不同二是如果把当前 shell 放进去注意别把关键操作也一起限制进去。想恢复时把进程移回根组即可echo$$/sys/fs/cgroup/cgroup.procsrmdir/sys/fs/cgroup/demo5.3 常用控制项对照cgroup v2 的 memory 控制器项比较多关键几个如下文件作用工程上的典型用法memory.max硬上限超过触发回收/ OOM容器内存限额、服务隔离memory.high软上限超过只限速不强杀先限速削峰避免直接 OOMmemory.current当前用量监控面板核心指标memory.stat分类统计明细定位是匿名页还是文件页占多memory.swap.max该组可用 swap 上限决定匿名页能否换出memory.oom.group是否整组同杀强绑定进程组的原子性需求设计取舍在于memory.max简单直接但容易一刀切memory.high更温和先让进程变慢而不是直接死适合在线服务削峰。生产上常见组合是两者都设memory.high略低于memory.max给回收留出反应时间。6. memory.stat 怎么读6.1 核心字段含义要判断一个 cgroup 为什么到上限直接看memory.stat。它不是“当前用了多少”那么简单而是告诉你钱花在哪一类内存上。下面抽取关键字段$cat/sys/fs/cgroup/demo/memory.stat anon178257920file10485760kernel33554432slab18874368sock4096file_dirty0pgscan18234pgsteal15120pgmajfault4211读法要点anon是匿名页通常是进程堆栈增长快且难回收file是文件页缓存可回收kernel和slab是内核占用pgscan/pgsteal反映该组内回收扫描和成功回收的页数持续增长说明组内一直在做回收。下面这张表把“现象”和“该看哪个字段”对应起来现象优先看的字段说明内存缓慢上涨不降anon 持续增长可能是应用层泄漏大量读写文件后内存高file 占比大通常是缓存可回收回收频繁但降不下来pgscan 高而 pgsteal 低匿名页多回收效率差缺页中断高伴随延迟pgmajfault 增长可能在反复换入匿名页6.2 用 memory.stat 区分两类“内存高”看一个实际判断过程。某服务memory.current长期贴着memory.max运维怀疑泄漏。第一步对比anon和file如果file占大头多半是缓存问题不大如果anon占大头且只涨不降才更可能是真正的常驻增长。第二步看pgscan和pgsteal。若pgscan很大但pgsteal很小说明内核一直在努力回收却收效甚微典型的匿名页过多、swap 不足。此时即使还没 OOM服务延迟也已经被拖坏了。第三步看pgmajfault。这个值持续增长意味着进程在反复触发需要磁盘 I/O 的缺页往往和 swap 换入相关。把它和宿主机的pswpin一起看就能判断 swap 压力是否已经传导到业务。7. 完整走一遍从申请到被杀现在把前面所有零件串起来模拟一个完整生命周期。假设宿主机 16GB某 cgroup 限额 1GB服务在组内运行。时间线 T0 服务常驻 anon200MB运行平稳 T1 突发请求涌入anon 涨到 900MB接近 memory.max1GB T2 继续分配 - 组内直接回收 - pgscan 上升pgsteal 有限 T3 memory.current 触顶组内回收失败 T4 cgroup v2 OOM 触发扫描组内进程 T5 计算组内 badness叠加各自 oom_score_adj T6 杀掉组内最高分进程dmesg 与 cgroup 事件记录 T7 若 memory.oom.group1整组进程一起被杀每一步对应可观测信号如下T2 阶段可以在memory.stat看到pgscan增长T3 阶段memory.current贴近memory.maxT4 之后dmesg出现Memory cgroup out of memoryT6 之后/sys/fs/cgroup/组/memory.events里的oom计数加一。这就是为什么排障时不能只看一个数字。只看memory.current会错过回收压力只看dmesg会错过前期征兆只有把时序拉出来才能判断是“突发尖峰”还是“持续泄漏”。8. OOM 日志定位谁动的手为什么是它8.1 全局 OOM 日志全局 OOM 的现场在dmesg或/var/log/messages不同发行版位置不同。典型片段如下Out of memory: Killed process 12345 (java) total-vm:8451234kB, anon-rss:6543210kB, file-rss:1024kB, shmem-rss:0kB读这段日志要抓四个信息进程号和名字、总虚拟内存、匿名 RSS、文件 RSS。这里anon-rss远大于file-rss说明它是靠匿名内存占满系统的和前面“匿名页难回收”的判断一致。在杀进程之前内核通常会打印一段Tasks state列出各进程的pid、oom_score_adj、total_vm、rss并标记其中一个为[pid] *星号就是被选中的那个。把这份清单和进程的实际用途对照就能解释“为什么杀它”。8.2 cgroup OOM 日志cgroup v2 的日志措辞不同通常会带组路径Memory cgroup out of memory: Killed process 23456 (python3) total-vm:1200000kB, anon-rss:1024000kB看到Memory cgroup out of memory就要立刻明白这是组内限额触发的跟宿主机整体内存没关系。定位时把组路径找出来去对应目录读memory.events和memory.stat$cat/sys/fs/cgroup/demo/memory.events low0high12max40oom3oom_kill3max表示触及硬上限的次数oom表示触发 OOM 的次数oom_kill表示真的杀了进程的次数。如果max一直在涨但oom_kill不涨说明memory.high在起作用进程被限速但还没死如果oom_kill也在涨那就是反复被杀必须处理根因而不是简单重启。8.3 一个可复现的定位实例下面这个完整示例把 cgroup OOM 和日志、事件文件串起来。前置环境是 cgroup v2 测试机、root 权限、Python3。# 示例三制造一次 cgroup OOM 并完成定位mkdir-p/sys/fs/cgroup/oomdemoecho150M/sys/fs/cgroup/oomdemo/memory.maxecho0/sys/fs/cgroup/oomdemo/memory.swap.maxecho$$/sys/fs/cgroup/oomdemo/cgroup.procs# 申请超过上限的内存python3-c buf [] for i in range(400): buf.append(bytearray(1024 * 1024)) print(allocated, len(buf)) echo--- events ---cat/sys/fs/cgroup/oomdemo/memory.eventsecho--- stat ---cat/sys/fs/cgroup/oomdemo/memory.statecho--- dmesg ---dmesg|tail-20执行后分三步定位。第一步看命令是否被信号杀死通常在申请到 150MB 左右就终止。第二步看memory.eventsoom_kill至少为 1证明组内 OOM 确实发生。第三步看dmesg找到Memory cgroup out of memory那几行对照被杀的python3。边界与注意点memory.swap.max0会让回收手段更少、更早触发 OOM生产上不应随意设 0否则瞬时尖峰没有缓冲。9. 常见误区误区一内存用到 100% 就一定会 OOM。实际上文件页缓存可以被回收free里的used高很多时候只是缓存。真正危险的是available接近 0 且匿名页多、swap 不足。误区二oom_score_adj-1000表示绝对不会被杀。它只是把偏移拉到最低在极端全局 OOM 下仍可能被杀。它是优先级不是豁免权。误区三cgroup OOM 就是全局 OOM。两者触发条件、扫描范围、日志关键词都不同。cgroup OOM 发生时宿主机可能还有大量空闲内存只看全局指标会漏判。误区四改大memory.max就能解决问题。如果根因是泄漏放宽上限只是把爆炸时间推后还会让组内其他进程一起受害。先看memory.stat里anon是否持续增长。误区五加了 swap 就不会 OOM。swap 只是延长存活时间大量换出换入会严重拖慢延迟在线服务可能先被超时打垮。10. 生产实践建议在部署阶段就固化优先级核心服务用OOMScoreAdjust设置为负值降低被杀概率离线任务、可重跑任务设为正值优先牺牲。systemd 单元比运行时改/proc更可靠。容器化环境下优先用 cgroup v2 的memory.max做硬隔离并用memory.high做软限速。两者配合可以在真正 OOM 之前让进程先变慢给流量调度争取时间。监控层面至少采集四类指标memory.current与memory.max的比值、memory.stat里的anon、memory.events里的oom_kill增长速率、宿主机allocstall与pswpout。只盯全局内存使用率是发现不了 cgroup 局部故障的。对延迟敏感的服务swap 策略要明确要么关掉并接受更快更干脆的 OOM要么保留少量应急 swap 但设好memory.swap.max避免匿名页被大规模换出。最后OOM 不是根因是结果。每次 OOM 后都应该回答“是哪类内存涨上去的、涨了多久、有没有回收压力”再决定是调参、扩内存还是修代码。11. 排障清单步骤目的关键命令或文件判断标准1确认内存整体状态free -havailable是否接近 02看回收压力grep allocstall /proc/vmstat是否持续增长3看 swap 压力grep pswpout /proc/vmstat换出是否频繁4看是否 cgroup OOMdmesg搜Memory cgroup有则聚焦对应组5看组内分类用量memory.statanon是否持续增长6看组内事件计数memory.eventsoom_kill是否在涨7看候选优先级/proc/pid/oom_score_adj是否设置了合理偏移8复盘根因应用日志加内存曲线是泄漏还是突发尖峰使用顺序建议从 1 到 5 快速扫一遍先分清“全局还是 cgroup”再决定深挖方向。顺序反了容易在错误的方向上花时间。12. 面试/复盘问题为什么内核不在内存用满的第一时间就杀进程而是先做回收oom_score和oom_score_adj分别是什么哪个可写全局 OOM 与 cgroup v2 OOM 的扫描范围有什么本质区别memory.high和memory.max的行为差异是什么生产中怎么组合使用memory.stat里anon和file都很大时如何判断哪个更危险pgscan很高但pgsteal很低说明什么问题为什么给服务设置oom_score_adj-1000仍不能保证绝对安全这些问题能答清楚基本就掌握了从触发条件到选择逻辑再到定位方法的整条链路。13. 总结把全文收成一张决策图发现服务异常退出 | v 查 dmesg 是否有 OOM 记录 | -- 无 -- 不是 OOM转向其他方向 | -- 有 -- 看关键词 | ----------------------- | | v v Out of memory Memory cgroup out of memory 全局 OOM 组内 OOM | | v v 看全系统 available 看对应组 memory.max 看各进程 oom_score_adj 看 memory.stat / events | | ----------------------- v 判断匿名页增长还是突发尖峰 | v 调参 / 扩内存 / 修代码核心结论有三条。第一OOM 是回收失败后的兜底手段判断危险不能只看内存使用率要看available、回收压力和 swap。第二选人逻辑是打分加人工偏移oom_score_adj是部署阶段就能固化的优先级策略。第三cgroup v2 把 OOM 的边界缩到控制组内部排障时必须先分清是全局还是组内再看memory.max、memory.stat和memory.events。掌握这三条再遇到凌晨的 OOM 告警你就能从猜测切换到有据可依的定位流程。14. 参考资料Linux 内核文档Control Group v2Documentation/admin-guide/cgroup-v2.rstLinux 内核源码mm/oom_kill.cOOM 打分与选择逻辑Linux 内核源码mm/memcontrol.ccgroup 内存控制器与 OOM 处理man 5 proc/proc/pid/oom_score与oom_score_adj说明man 5 systemd.execOOMScoreAdjust配置项man 1 free、man 5 proc中关于内存统计字段的说明

Linux 内存不足时 OOM Killer 的选择逻辑与 cgroup 限制下的行为差异

相关推荐

高校人事管理系统微服务架构设计与实践

STM32内部温度传感器ADC+DMA采样滤波与两点校准详解

PPT图片压缩全攻略：三个核心技巧，轻松为PPT演示文稿“瘦身”

更多资讯

Flutter与鸿蒙融合中的依赖版本管理实践

LightRAG架构优化：提升AI问答系统性能的关键技术

OpenCV与C#实现工业级直线卡尺测量工具

YOLO v11架构升级：从检测框架到端到端感知引擎

Python生成器原理与应用：从惰性求值到协程实践

NI工业AI测试：边缘原生与信号级嵌入的闭环实践

今日更新

基于MATLAB的CRI显色指数计算：从SPD光谱到Ra的完整流程

JSP+Servlet+MySQL博客系统源码部署与优化全攻略

蜂窝调度算法 MATLAB 实现：比例公平、轮询与最大 C/I 对比

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？