容器OOM Kill排查：cgroup v2与namespace全解析

凌晨两点，监控突然拉响，线上一个 Java 服务的容器被重启。冲进宿主机翻 dmesg，看到一行 oom-kill 记录：Killed process 45821 (java)，但此时容器已经被 restart，进去 ps 根本找不到这个 PID。这个场景，估计每个做 Linux 服务器运维的人都经历过。OOM Killer 作为内核最后一道内存防线，平时安安静静，一旦触发就是生产事故。而我们要做的深度监控，恰恰要在这道防线开火之前和开火瞬间，把进程、cgroup、namespace 三个维度的信息全部抓全——这不只是看日志，而是要把内核的判决逻辑、容器资源账本和 PID 隔离带来的映射关系彻底搞清楚。

这篇文章我把自己这两年在生产环境里折腾 OOM 监控的完整思路写下来，包括内核触发原理、cgroup v2 的监控接口、namespace 下的还原手段，以及一套可以直接部署的脚本。全文不是教科书式的参数罗列，而是从实际踩坑出发，尽量把“为什么这么配”“为什么这里会踩坑”讲透，适合负责服务器稳定性、容器编排的运维和 SRE 参考。

1. 内核在什么情况下会开枪：OOM Killer 的触发与选人逻辑

1.1 三种 overcommit 模式决定了你的内存账本怎么算

要理解 OOM Killer，先要接受一个反直觉的事实：Linux 的 malloc 大部分时候是在“吹牛”。进程申请 1GB 内存，内核可能当场就点头，但这 1GB 物理页并不会真的分配出来，只有进程实际去读写这些地址时，内存页才会被真正占用。这种“允许超额承诺”的机制叫 overcommit，它是 Linux 多进程内存共享、写时复制等特性的基础，但也让“内存到底够不够”变成一笔糊涂账。

内核用 /proc/sys/vm/overcommit_memory 控制这笔账怎么算，取值主要是 0、1、2 三档：

严格模式下的 CommitLimit 由 vm.overcommit_ratio 决定，公式是：

code复制CommitLimit = SwapTotal + 物理内存 * vm.overcommit_ratio / 100

ratio 默认 50，也就是说系统最多承诺物理内存一半的额外超卖空间。这里有个常见的监控盲区：很多人只盯 free -h，看到还有几个 GB 就放心了，实际上在 overcommit_memory=2 的机器上，/proc/meminfo 里的 Committed_AS 才是真正的风险指标。这个值表示内核已经承诺给所有进程的地址空间总量，一旦它逼近 CommitLimit，即使 MemFree 还有剩余，新的内存申请也可能直接失败。

我遇到过一次很诡异的故障：Java 服务反复启动失败，日志里报“OutOfMemoryError：unable to create native thread”，不是进程被杀，是线程栈内存分配直接被拒。排查到最后才发现是某个人把 overcommit_memory 改成了 2，Java 这种吃地址空间的进程首当其冲。所以深度监控里必须包含这两个字段：Committed_AS 和 CommitLimit，它们能给你一个提前量。

1.2 badness 评分：为什么总杀掉你觉得"不该杀"的进程

当内核真的走到山穷水尽——kswapd 回收无效，直接回收也无效，再不放血整个系统就要卡死——它会启动 out_of_memory 流程，挑一个进程杀掉。关键问题是：它怎么挑？

内核给每个进程算一个 badness 分数，核心逻辑在 oom_badness() 这个函数里，主要看这几个因素：

• 进程占用的内存总量（RSS + swap + 页表占用的页面数），占分最大；
• 进程已经运行了多久，刚启动不久的进程分数会偏高，因为内核认为“短命鬼”杀掉代价小；
• 进程的父进程、子进程关系，以及它是不是 root 启动的关键任务；
• 是否处于不可中断的 D 状态等特殊情况。

最后的评分会被 /proc/<pid>/oom_score_adj 做线性修正，这个值范围是 -1000 到 1000，默认继承父进程，绝大多数进程是 0。写成 -1000 意味着“永远别杀我”，等于拿到免死金牌；写成正数则是主动吸引火力。最终算出来的总分写在 /proc/<pid>/oom_score 里，范围 0 到 1000。

这就解释了为什么很多时候被杀的不是你觉得“内存占用最猛”的常驻服务，而是刚启动的批处理任务。有一次我这边跑数据导出的 Python 脚本被反复 OOM kill，服务端 Java 进程反而毫发无损，原因就是那个脚本一次性加载几百万行数据，RSS 瞬间飙高，同时又刚启动没几分钟，badness 分数直接压过所有老进程。

如果要主动保护某些核心进程，可以用 systemd 的 OOMScoreAdjust= 直接调：

ini复制[Service]
ExecStart=/usr/local/bin/order-service
OOMScoreAdjust=-800

同样，给那些“宁可被杀也不能拖垮全局”的临时任务设置正分。这里要强调的是，oom_score_adj 不是越大越安全，它不是优先级队列，而是“杀掉分数最高那一个”，所以如果你把一堆进程都调成正分，那内核只是在矮子里面拔将军，保护效果会大打折扣。

2. 只靠 dmesg 做监控远远不够：事件之外还得有上下文

2.1 dmesg 日志不够用的三个理由

很多人查 OOM 的第一反应是翻 dmesg -T | grep -i oom，这没错，但如果你用这个做过线上复盘，很快就会发现它远远不够。

第一，内核日志是环形缓冲区，dmesg 默认大小有限，日志量大时早前的 OOM 记录可能已经被冲刷。尤其在高并发系统上，网络、磁盘、驱动都在刷日志，OOM 记录很容易被顶掉。第二，日志里只有进程的 comm 和全局 PID，没有业务上下文——那个 java 到底是订单服务还是报表服务？它在哪个容器、哪个 pod、哪个 cgroup 下？这些 dmesg 一概不给你。第三，没有“触发前的趋势”。OOM 不是瞬间发生的，内存是被一步步吃完的，但 dmesg 只给你最后判决的那一行，没有水位曲线，你就没法判断是突刺还是缓慢泄漏。

真实排查里还有一个更隐蔽的问题：comm 会被内核截断到 15 个字符。Java 的线程名、Python 脚本名稍长一点，你在日志里看到的可能只是 python3 或者 java，根本看不出是哪个业务。

2.2 把 OOM 事件、内存快照、进程树串成一条结构化记录

既然 dmesg 的信息密度不够，深度监控的做法就是“事件驱动 + 上下文快照”。也就是说，不去依赖 dmesg 里的那一行，而是等 OOM 事件发生的那一瞬间，主动去采集三组数据：

• 事件层：谁触发了 OOM（内核日志里会标明是 CONSTRAINT_MEMCG 还是全局）、杀的是哪个进程、进程的全局 PID 和 comm；
• 环境层：触发前的 /proc/meminfo 关键字段、对应 cgroup 的 memory.current、memory.max、swap 使用量；
• 现场层：被杀进程的完整信息，包括 oom_score、oom_score_adj、父进程、cgroup 路径、cmdline、NSpid。

把这些数据拼成一条 JSON，落到单独的文件或告警平台，才叫“可复盘的监控”。我举个例子，一条完整的 OOM 现场记录大致长这样：

json复制{
  "timestamp": "2025-06-11T03:22:18.231Z",
  "event": "oom_kill",
  "killed_pid": 45821,
  "killed_comm": "java",
  "killed_cgroup": "/kubepods/burstable/pod-abcdef/cri-o-xxxx.scope",
  "meminfo": {
    "MemFree_kb": 182344,
    "MemAvailable_kb": 302198,
    "Committed_AS_kb": 16854032,
    "CommitLimit_kb": 16777216
  },
  "memcg": {
    "current_bytes": 64424509440,
    "max_bytes": 64424509440,
    "swap_current_bytes": 1024000,
    "swap_max_bytes": 0
  },
  "process": {
    "oom_score": 892,
    "oom_score_adj": 0,
    "nspid": [45821, 7],
    "ppid": 1,
    "cmdline": ["/usr/bin/java", "-Xmx8g", "-jar", "order-service.jar"],
    "exit_signal": 9
  }
}

有了这条记录，你能一眼看出：这是 cgroup 内存限制被击穿导致的 OOM，Java 进程在容器内的 PID 是 7，当时的 RSS 已经把 cgroup 限额吃满，同时全局 Committed_AS 也逼近了 CommitLimit——既有 cgroup 限制问题，也有宿主机内存水位偏高的隐患。后面第三、四节会展开讲这两类数据是怎么采集和关联的。

3. 把台账算到容器粒度：cgroup v2 限制与感知 OOM 的接口

3.1 memory.max 是硬线，memory.high 是软线：两者配合才有弹性

容器时代谈内存，不能再以“整个宿主机”为粒度了，必须落到 cgroup。现在新发行版基本都是 cgroup v2，统一挂载在 /sys/fs/cgroup 下，配置接口比 v1 清爽很多。对监控来说，最核心的是这两个文件：

• memory.max：硬限制，超过之后内核会尝试回收，回收不动就会触发 OOM kill；
• memory.high：软限制，超过之后内核会对该 cgroup 的进程进行限流和积极回收，但不会立刻杀进程。

这两个限线的定位完全不同。memory.high 像一个“警告水位”，它的作用是让 cgroup 内的内存使用在撞到 memory.max 之前就开始主动收缩，代价是进程的分配速度会被拖慢，极端情况下会出现卡顿。memory.max 才是最后的墙，撞上去就是两条路：要么回收成功，要么放血。

实操中很容易踩的坑是只设 memory.max 不设 memory.swap.max。在 cgroup v2 里，如果只限制内存不限制 swap，进程实际可以使用的内存上限是 memory.max + memory.swap.max，默认 swap.max 通常是“不限”，于是容器在 swap 充足的情况下会把数据换出去，表面看没问题，但整机 swap 被打满后，所有进程都会变慢。所以我这边管理的容器统一都会显式设置 MemorySwapMax=0，要么就别给 swap 幻想。

配置上，systemd 运行的服务可以直接在 unit 里写：

ini复制[Service]
MemoryMax=4G
MemoryHigh=3G
MemorySwapMax=0

MemoryHigh 是给那些“允许限流不允杀”的业务用的，比如对时延不敏感的数据批处理任务。而核心在线服务，我建议 High 可以稍微留一点空间，但 Max 必须严格，宁可它被杀重启，也不能让它抢占整台机器的内存。

3.2 用 memory.events 做事件驱动，用 PSI 做提前量

在 cgroup v2 下，规范的做法是监控 /sys/fs/cgroup/<路径>/memory.events。这个文件是稳定接口，长这样：

code复制low 0
high 0
max 0
oom 0
oom_kill 0
oom_group_kill 0

其中 max 表示撞到硬限制的次数，oom 表示进入过 OOM 流程的次数，oom_kill 表示实际杀过进程的次数。这些是计数器，只会累加。深度监控的思路是定期记录这些计数器的值，如果发现 oom_kill 增量大于 0，立刻触发现场快照。这比轮询 dmesg 可靠得多，因为它直接反映“这个 cgroup 内部发生的事”，不会受全局环形缓冲区的冲刷影响。

再往前一步，就是 PSI（Pressure Stall Information）。PSI 是内核提供的资源压力指标，读取 /proc/pressure/memory 可以得到类似这样的输出：

code复制some avg10=12.34 avg60=8.90 avg300=5.67 total=293849102
full avg10=3.21 avg60=1.98 avg300=1.02 total=102938475

some 表示有部分任务因为内存分配而阻塞的时间比例，full 表示所有任务都阻塞的时间比例。这个指标的价值在于它发生在 OOM 之前。当 full avg10 持续超过 10%，说明已经有任务被内存回收拖得无法推进，此时虽然进程还没被杀，但系统已经处于亚健康状态，正是扩容或者调整参数的窗口期。我现在的做法是把 PSI 接入 Grafana，full avg10 超过阈值就告警，这比等 oom_kill 事件被动响应要舒服得多。

3.3 oom.group：杀一个还是杀一窝？容器场景下的选择

cgroup v2 还有一个容易忽略的开关：memory.oom.group，默认是 0。它的作用是：当该 cgroup 内部触发 OOM 时，内核会杀掉整个 cgroup 里的所有进程，而不是只杀 badness 分数最高的那一个。

这个开关在容器场景下有非常实际的意义。默认情况下，一个容器内的进程如果发生 OOM，内核只杀最胖的那个进程。假设你的容器里同时跑着 Java 主进程和一个负责日志采集的 sidecar，那被杀的可能只是 Java 进程，sidecar 还活着，容器本身也没退出，K8s 探针可能短时间内探测不到异常，业务进入一种“半死不活”的状态，这比直接崩了更难排查。

如果把 memory.oom.group 设为 1，内核会在触发 OOM 时杀掉该 cgroup 内所有进程，让容器整体退出，之后交给编排系统按照 restartPolicy 重新拉起。这等于把“故障边界”和“故障单元”对齐了——要么整个容器一起死，要么整个容器一起活，不存在中间态。配置方法很简单：

bash复制echo 1 > /sys/fs/cgroup/system.slice/my-service.service/memory.oom.group

systemd 管理的服务可以通过 unit 文件加 OOMPolicy= 配合，不过 oom.group 更直接的还是写这个文件。容器平台里，Kubelet 管理的 pod 对应的 cgroup 路径下也适用。需要谨慎的是，这个开关对“同一个 cgroup 里既有核心服务又有辅助进程”的场景要三思，杀一窝可能会扩大爆炸半径；但从稳定性的角度看，快速失败、快速重启，通常好过带病运行。

4. namespace 隔离带来的监控盲区：如何从宿主机还原现场

4.1 一条典型的容器 OOM 记录，日志里看到的 PID 是"假的"

如果说 cgroup 解决的是“内存账本归谁”的问题，那 namespace 解决的是“进程身份怎么映射”的问题。这两者叠加在一起，构成了容器 OOM 排查里最容易头晕的部分。

举个典型例子。你在宿主机 /var/log/kern.log 里看到这行：

code复制oom-kill:constraint=CONSTRAINT_MEMCG,oom_memcg=/docker/abc123,oom_kill_allocating_task=0,pid=45821,name=java

于是你登录容器，输入 ps -ef | grep java，发现根本没有 45821 这个 PID，甚至进容器的进程都已经是新的 PID 了。这不是错觉，而是 PID namespace 在起作用。容器内进程看到的 PID 是它在当前 namespace 内的编号，而内核日志记录的是全局 PID，也叫 host PID。如果容器里 Java 是主进程，它在容器内看到的 PID 可能就是 1 或者 7，但它在宿主机视角下可能是 45821。

很多人在这一步就卡住了，最后只能从 docker inspect 里看 OOMKilled: true 和退出码 137，拿不到更多线索。要还原现场，必须掌握 host PID 到容器内 PID 的映射方法。

4.2 用 NSpid 字段完成 PID 映射，用 nsenter 进入现场取证

好在内核从 4.2 开始，在 /proc/<pid>/status 里提供了一个关键字段：NSpid。它会把一个进程在各级 PID namespace 下的 ID 成列展示，最左边是全局 PID，往右依次是内层 namespace 的 PID。

假设 OOM 发生时，/proc/45821/status 里能看到：

code复制NSpid: 45821	7

这就说明全局 PID 45821 的进程，在它的 PID namespace 里编号是 7。如果容器里再嵌套容器，这个列表会更多，比如 NSpid: 45821 867 2。从宿主机直接读这个文件，就能完成映射。

但这里有个残酷的现实：如果进程已经被杀了，/proc/<pid> 目录就没了，NSpid 信息自然也无从读取。所以我在监控脚本里的做法是：在检测到 oom_kill 计数变化的瞬间，立刻读取 /proc/<killed_pid>/status 和 /proc/<killed_pid>/cgroup、/proc/<killed_pid>/cmdline，趁进程尸体还热着把信息抓全。这也是为什么说“实时监控”而不是“事后查日志”。

如果发生 OOM 的容器还活着，只是想进去看看现场，可以用 nsenter 直接进入容器的 PID namespace：

bash复制nsenter -t 45821 -p ps -ef

这条命令从宿主机视角进入 45821 所在的 PID namespace，执行 ps，就能看到“容器内视角”的进程列表。同理，用 nsenter -t 45821 -n 可以进入网络 namespace，排查网络相关的现场。

4.3 K8s 里 OOMKilled 的完整事件链：从内核到容器状态

在做 K8s 时，OOM 的事件链会比单机 docker 长一些，但底层逻辑不变。整个链路是这样的：

1. 容器内进程超卖，撞到 memory.max，内核执行 OOM kill；
2. 被杀的进程收到 SIGKILL，容器运行时（containerd/cri-o）记录退出码 137；
3. kubelet 根据退出码和运行时上报信息，把容器状态标记为 OOMKilled，生成一个事件；
4. 如果 restartPolicy 允许，kubelet 重新拉起容器。

对运维人员来说，kubectl describe pod 里能看到类似 Reason: OOMKilled、Exit Code: 137 的信息，kubectl get pod xxx -o yaml 的 lastState.terminated 里也有详细字段。这些信息够你做第一层判断：确实是 OOM，而且知道是哪个容器。

但 K8s 状态信息不会告诉你是“哪个 cgroup、哪个具体进程、当时 memory.current 是多少”。这时候我的排查路径很固定：先去 pod 所在的节点，找到对应 pod 的 cgroup 路径，然后查 /sys/fs/cgroup/kubepods.slice/.../memory.events 里的 oom_kill 计数，再结合监控快照看被杀的 host PID 是哪个。这里的关键 mapping 是通过 cgroup 路径关联的：每个 pod 有一个唯一的 uid，cgroup 路径里也会带这个 uid，对上了，就能锁定到业务。

还有一个细节：K8s 节点上的 kubelet、dockerd 这些系统进程如果被 OOM 误杀，整台节点会失控，所以平台组件通常会把自己的 oom_score_adj 调成负数。你检查生产节点时，应该确认 kubelet 进程有类似 OOMScoreAdjust=-900 的保护，别让基础设施成为第一批牺牲品。

5. 生产落地：内核参数、监控脚本与受控演练

5.1 内核参数调优：哪些该调、哪些别碰

关于内核参数，必须先说一句：绝大多数服务器保持默认就是最优解，瞎调只会引入新故障。但有几个参数值得检查和按需调整，我列个表说明：

调 watermark_scale_factor 是一个比较容易被忽视的优化点。它控制内存水位线距离最小值的高度的比例，默认 10 意味着水位线 = min_free_kbytes * 1/10 的粒度，调大后 kswapd 提前介入回收，内存分配高峰到来时更不容易直接进入直接回收甚至 OOM 流程。对于内存波动大的业务，可以适当调大，但要注意提前回收会带来 CPU 开销和分配时延。

另外，新版 systemd 提供了 systemd-oomd，这是用户态的 OOM 守护进程，通过 cgroup v2 的 PSI 数据在系统整体内存压力过高时，对标记了 ManagedOOM=kill 的 cgroup 发送 SIGTERM，而不是等内核直接 SIGKILL。这在“优雅缩容”场景下挺有用，但配置时要小心，先在测试环境观察几周，确认它不会误杀业务。

5.2 一套可直接部署的 OOM 监控脚本

我做监控的原则是“少依赖、易排错、能落地”，所以选型是 Python 3 标准库 + systemd，不引入额外的 agent。核心逻辑很简单：定期读取指定 cgroup 的 memory.events，记录 oom_kill 计数；发现增量时，立即采集现场数据并写入 JSON 日志，同时可以调一个 webhook 发告警。

下面是一个精简但可用的版本：

python复制#!/usr/bin/env python3
import argparse
import json
import subprocess
import time
from datetime import datetime, timezone
from pathlib import Path

CGROUP_BASE = Path("/sys/fs/cgroup")

def read_events(cg: Path) -> dict:
    result = {}
    try:
        for line in (cg / "memory.events").read_text().strip().splitlines():
            k, _, v = line.strip().partition(" ")
            result[k] = int(v)
    except FileNotFoundError:
        pass
    return result

def snapshot(cg: Path) -> dict:
    def read_int(name: str):
        try:
            return int((cg / name).read_text().strip())
        except OSError:
            return -1
    return {
        "current": read_int("memory.current"),
        "max": read_int("memory.max"),
        "swap_current": read_int("memory.swap.current"),
        "swap_max": read_int("memory.swap.max"),
        "events": read_events(cg),
    }

def collect_process_context(pid: int) -> dict:
    ctx = {"pid": pid, "nspid": [], "cmdline": [], "oom_score": -1, "oom_score_adj": -1}
    status_path = Path(f"/proc/{pid}/status")
    try:
        for line in status_path.read_text().splitlines():
            if line.startswith("NSpid:"):
                ctx["nspid"] = line.split()[1:]
            if line.startswith("OomScore:"):
                ctx["oom_score"] = int(line.split()[1])
            if line.startswith("OomScoreAdj:"):
                ctx["oom_score_adj"] = int(line.split()[1])
        cmdline = Path(f"/proc/{pid}/cmdline").read_bytes().decode("utf-8", "replace").split("\0")
        ctx["cmdline"] = [x for x in cmdline if x]
    except OSError:
        pass
    return ctx

def get_killed_pid_from_kernel_logs() -> int:
    # 读取内核环形缓冲最近一条 oom-kill 记录，提取 killed pid
    try:
        out = subprocess.check_output(
            ["dmesg", "-T"], stderr=subprocess.DEVNULL, text=True
        ).splitlines()
    except Exception:
        return -1
    for line in reversed(out):
        if "oom-kill" in line or "Killed process" in line:
            parts = line.split()
            for i, p in enumerate(parts):
                if p in ("process", "pid="):
                    try:
                        return int(parts[i + 1])
                    except (IndexError, ValueError):
                        pass
    return -1

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--cgroup", action="append", default=[], help="cgroup 路径，可多次指定")
    parser.add_argument("--interval", type=int, default=5)
    parser.add_argument("--webhook", default="")
    args = parser.parse_args()

    watched = [Path(p) for p in args.cgroup] if args.cgroup else [CGROUP_BASE]
    last_count = {}
    for cg in watched:
        last_count[str(cg)] = read_events(cg).get("oom_kill", 0)

    while True:
        time.sleep(args.interval)
        for cg in watched:
            events = read_events(cg)
            current = events.get("oom_kill", 0)
            key = str(cg)
            if current > last_count.get(key, 0):
                killer_pid = get_killed_pid_from_kernel_logs()
                record = {
                    "timestamp": datetime.now(timezone.utc).isoformat(),
                    "cgroup": key,
                    "events": events,
                    "delta_oom_kill": current - last_count[key],
                    "snapshot": snapshot(cg),
                    "killed_pid": killer_pid,
                    "process": collect_process_context(killer_pid) if killer_pid > 0 else {},
                }
                out_path = Path(f"/var/log/oom_monitor/{datetime.now():%Y%m%d}.jsonl")
                out_path.parent.mkdir(parents=True, exist_ok=True)
                with out_path.open("a") as f:
                    f.write(json.dumps(record, ensure_ascii=False) + "\n")
                if args.webhook:
                    subprocess.Popen(
                        ["curl", "-s", "-X", "POST", args.webhook,
                         "-H", "Content-Type: application/json",
                         "-d", json.dumps(record)], stdout=subprocess.DEVNULL,
                        stderr=subprocess.DEVNULL,
                    )
                last_count[key] = current

if __name__ == "__main__":
    main()

用 systemd service 跑起来的方式：

ini复制[Unit]
Description=OOM Monitor
After=network.target

[Service]
ExecStart=/usr/local/bin/oom_monitor.py --cgroup /system.slice/my-app.service --webhook https://hooks.example.com/alert
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

脚本里有几个细节值得说。第一，cgroup 路径用 --cgroup 逐条指定，比全量扫描好，因为全量扫描 /sys/fs/cgroup 会伴随大量层级目录，产生无意义快照。第二，get_killed_pid_from_kernel_logs() 是一个兜底手段，因为 memory.events 只告诉你这个 cgroup 发生过 OOM kill，但不直接告诉你 process PID，所以需要从内核日志里反查最新一条 oom-kill 记录。第三，采集进程上下文必须在 dmesg 反查后立刻执行，因为 PID 随时可能被回收。

如果有条件，我更建议直接把事件发到 Kafka 或 ClickHouse 这类中心化存储，方便跨节点搜索历史 OOM 曲线，而不是只留在本机 JSONL 文件里。

5.3 用 systemd-run 制造一次受控 OOM，验证全链路

任何监控方案不演练等于没做。我最推荐的方式是用 systemd-run 创建临时 scope，用参数把内存限制死，然后 runaway 内存，制造一次受控 OOM。这样不会影响系统其他部分，并且可以直接观测整个事件链。

步骤如下：

bash复制# 创建一个临时 scope，限制内存 64M，禁止 swap
systemd-run --scope --unit=oom-test \
  -p MemoryMax=64M -p MemorySwapMax=0 \
  sh -c 'stress-ng --vm 1 --vm-bytes 256M --timeout 5s'

stress-ng 里的 --vm 1 表示一个虚拟内存压力线程，--vm-bytes 256M 会一次性申请 256MB，远超 64MB 限制，几秒内必然触发 OOM kill。运行之后你应该能在另一个终端看到：

bash复制dmesg -T | tail -20

里面会有类似这行的内核记录：

code复制oom-kill:constraint=CONSTRAINT_MEMCG,oom_memcg=/system.slice/oom-test.scope,oom_kill_allocating_task=0,pid=37218,name=stress-ng

同时，监控脚本应该输出一条 JSON 记录，killed_pid 对应内核日志里的 37218，nspid 里通常只有一个值，因为没有嵌套 PID namespace。如果是容器环境，把 stress-ng 跑在容器里，配合 --cgroup 指定容器的 cgroup 路径，你就能验证 NSpid 两个值的映射是否正常。

再进一步验证 oom.group 的效果：先把 cgroup 里放两个进程，再打开 memory.oom.group 触发 OOM，观察是否两个进程都被杀。我建议在测试环境的临时 cgroup 下标定一下默认 Docker 容器的行为差异，因为运行时版本不同，cgroup 继承和 memory.oom.group 默认值可能有差异。

演练完成后别忘清理：

bash复制systemctl stop oom-test.scope
rmdir /sys/fs/cgroup/oom-test 2>/dev/null || true

我已经养成了每次有新内核或容器运行时版本上线，先跑一轮这种受控演练再上生产的习惯。OOM 这种故障平时不发生，但一旦发生就是高压时刻，只有链路验证过，出问题时才有底气按流程走。

最后说点个人经验。做 OOM 监控，最难的不是写脚本，而是把“内核全局视角”和“容器业务视角”两个维度缝起来。同样的一个 OOM 事件，从 dmesg 看是一串 PID 和内存数字，从 K8s 看是 OOMKilled 状态和退出码 137，从开发看只是“服务又重启了”——这三者对不上，排查就无从谈起。我每次都在事件记录里强制保留 cgroup 路径和 NSpid 字段，就是在给自己留一条“跨界取证”的通道。

还有一点：不要抱着“把 OOM 彻底消灭”的执念。只要 Linux 还在用 overcommit，只要容器还允许超卖，OOM 就不可能绝迹。成熟的做法是把它当成一个“快速失败 + 自动恢复 + 完备取证”的流程来设计，让每次 OOM 都能在几分钟内定位到业务和诱因。把监控链路、内核参数、cgroup 边界这些功课做在平时，真出事的时候，你只需要打开日志读结论就够了。