PSI 比 OOM 早 30 秒：cgroup v2 内存压力预警与一条能落地的告警规则

作者苏知远-813

cgroup-v2PSI内存OOMKubernetesSRE

结论先行：cgroup v2 的 PSI（Pressure Stall Information）是 OOM 之前少数几个"看得见"的信号之一。memory.max 触发 OOM 是阶跃事件——前一刻 RSS 还在涨，后一刻进程就没了，Prometheus 按 15s 采集根本抓不到峰值；而 memory.pressure 里的 full 字段，是内核在"内核正在替你回收内存、线程被强制脱机"的实时累计值。把 full > 10% 持续 60s 做成告警，能稳定比 oom_kill 事件早 20~30s 通知到人。下面是我在一次内核升级后的完整落地过程。

一、现象：升级到 cgroup v2 后，OOM 变得"没有预兆"

背景交代清楚，方便对号入座：

集群：Kubernetes 1.28.9，containerd 1.7.13，12 台 worker（8C32G）
内核：从 RHEL 8.6 的 4.18.0-372（cgroup v1）迁到 ALinux 3 的 5.10.134-16（cgroup v2）
业务：Java 17（-Xmx700m，Pod requests=1Gi / limit=1Gi，QoS=Guaranteed）

迁移前用 v1 时代的 memory.usage_in_bytes 做"水位告警"（>90% 触发），跑了两年基本够用。迁移后一个月内同一条 Java 服务 OOM 了 4 次，每次的特征都是：

memory.current 上一分钟还在 900MB 附近，下一分钟容器直接 OOMKilled；
memory.events 里 oom_kill 从 0 跳到 1（没有 max 触发的中间态可查）；
Prometheus 抓到的 container_memory_working_set_bytes 峰值是 1.04Gi——已经超过了 limit，说明这次采样落在 OOM 之后内核把 page cache 也算进去的瞬间，等于"事后验尸"，对下一次 OOM 毫无预警能力。

根因一句话：v1 的 memory.limit_in_bytes 触发前有一段"内核反复 retry reclaim"的软区间，usage 会在 limit 附近徘徊几分钟给你留时间；v2 的 memory.max 是硬切，一旦 reclaim 失败立刻走 oom_kill_process，中间没有可观测的"徘徊期"。这是机制差异，不是监控没做好。

二、原理：PSI 到底在算什么，为什么它比 RSS 早

PSI 内核在 4.20 引入（cgroup 版在 5.2 稳定），每个 cgroup 下都有 memory.pressure 文件。它统计的是**"该 cgroup 内的线程因为资源不足而被迫停滞（stall）的时间占比"**，分两档：

some：至少一个线程在等内存（reclaim 进行中）；
full：所有非空闲线程都在等内存（这个容器此刻完全跑不了活）。

关键机制：当 cgroup 内发生内存回收（kswapd 或 direct reclaim），内核会给正在被回收路径上阻塞的线程打时间戳，PSI 把这些 stall 时间累计到 total 字段。所以：

PSI 是"压力"，不是"水位"——RSS 到 95% 但页面都是干净的、reclaim 很便宜，PSI 可能只有 0.1%；反过来 RSS 才 70%，如果大量 anon 页要写回（v2 下容器默认 memory.swap.max=0，实际就是走 OOM），PSI 会飙到 100%。
PSI 是实时累计，不是采样值——cat memory.pressure 两次做差，得到的是这段时间内的平均 stall 占比，不会被 15s 的 Prometheus 采集周期"平均掉"。
full 接近 100% 时，下一次 memory.max 触发 OOM 只是时间问题——因为 full=100% 意味着内核已经在做 direct reclaim 且回收速度追不上分配速度，这是 OOM 的直接前兆。

一句话：RSS 告诉你"用了多少"，PSI 告诉你"内核有多忙在帮你救火"。OOM 是"救火失败"的结果，所以救火的忙碌度天然早于结果。

三、具体做法：从读文件到 Prometheus 告警，全链路可复现

3.1 手动验证：宿主机上读 PSI

# 找到 Java Pod 的 cgroup v2 路径
$ cat /proc/self/cgroup
0::/system.slice/containerd.service/kubepods.slice/kubepods-burstable.slice/\
kubepods-burstable-pod1234_....slice/cri-containerd-abcdef.scope

# 直接读 PSI（不需要进容器，宿主机上读即可）
$ cat /sys/fs/cgroup/.../cri-containerd-abcdef.scope/memory.pressure
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

压测时（我用的是一段 5 分钟循环 new byte[8MB] 不释放的 Java 小程序）观察到的时间线：

| 时刻 | RSS (memory.current) | full avg10 | |------|---------------------|-----------| | T+0s | 720 MB | 0.00 | | T+60s | 890 MB | 0.00 | | T+90s | 960 MB | 12.4 | | T+105s | 1.02 Gi | 47.8 | | T+118s | — | — | | T+119s | OOMKilled，memory.events.oom_kill=1 | — |

从 full avg10 > 10 到 OOM，稳定 20~30 秒——这就是告警窗口。

3.2 Prometheus 采集：cadvisor 原生支持

node_exporter 只采节点级 PSI（/proc/pressure/memory），看不到单容器。K8s 的 cadvisor 从 0.47 开始暴露 container_memory_pressure_full 和 container_memory_pressure_some（单位是 0~1 的小数，对应 PSI 的 avg10）。确认：

$ curl -s http://localhost:8080/metrics | grep container_memory_pressure
container_memory_pressure_full{name="cri-containerd-...."} 0.478

如果 cadvisor 版本偏老，可以自己写个 20 行的小 exporter：读 memory.pressure 的 total 字段，两次采集做差除以时间差，得到 rate。

3.3 告警规则（Prometheus 2.x，可直接抄）

- alert: ContainerMemoryPressureHigh
  expr: |
    rate(container_memory_pressure_full_total[2m]) > 0.10
    and on (namespace, pod) (container_memory_working_set_bytes
      > 0.8 * container_spec_memory_limit_bytes)
  for: 60s
  labels:
    severity: warning
  annotations:
    summary: "{{ $labels.pod }} 内存压力过高，OOM 风险"

两个条件缺一不可：

只看 PSI 不看水位：一个正常的 GC 抖动也会让 full 瞬时飙高，误报；
只看水位不看 PSI：水位 90% 但都是 page cache，实际很健康，误报。
两个条件叠加 = "水位高 + 内核正在吃力回收" = OOM 前兆，我线上跑了 6 周，4 次真实 OOM 全部提前 22~35s 告警，0 误报。

3.4 顺手把 `memory.events` 也采进来

$ cat .../memory.events
low 0
high 0
max 3
oom_kill 1
oom_group_kill 0

max 字段是"触发过 memory.max 的次数"（v2 新增），oom_kill 是实际杀进程的次数。max 涨了但 oom_kill 没涨，说明内核靠回收撑过去了，不用慌；两个一起涨，才是真出事。 这个字段 v1 没有，是迁移后白捡的观测点。

四、踩过的坑与反直觉之处

avg10/60/300 不是"过去 10/60/300 秒的平均"，而是指数加权滑动平均，初始权重不同。压测时我用 avg10 做触发条件，比 avg60 灵敏 3~5 倍，但噪声也更大——生产告警建议用 avg10，但 for 时间拉长到 60s 来过滤毛刺。
PSI 的 full 和 some 差值很大时，说明是"单线程卡住"而不是"整体压力"——比如某个线程在 mmap 大页、其他线程正常跑。这种场景 OOM 风险其实不高，告警阈值可以适当放宽。我一开始只监控 full，漏掉了一个"单线程反复 mlock 大页"的隐患，后来加了一条 some - full > 0.5 的辅助规则。
cgroup v2 下 memory.swap.max 默认就是 0（容器场景），所以 PSI 里的 stall 几乎全是"直接走 OOM 路径"，PSI 满 = OOM 倒计时，比 v1 时代（有 swap 缓冲）信号更强、更干净。这也是为什么我建议在 v2 环境下把 PSI 告警阈值设得比 v1 时代激进一档。
memory.current 包含 page cache，但 OOM 判定用的是"不可回收的部分"——所以你看到 RSS 1.05Gi > limit 1Gi 但没 OOM，是因为里面有 80MB 是干净的 page cache，内核随时能丢。反过来 RSS 900MB < limit 1Gi 但 OOM 了，是因为 anon 页太多、reclaim 追不上。这就是为什么"水位告警"在 v2 时代不可靠，必须上 PSI。
K8s 的 livenessProbe 不能替代 PSI 告警——OOM 发生时进程已经没了，探针再灵敏也是"事后确认"。PSI 告警的价值在于给 SRE 一个 30 秒的干预窗口（扩 limit、降级、kill 掉吃内存的线程），而不是"事后确认 OOM 发生了"。

五、结论与可复用清单

结论：cgroup v2 时代，内存 OOM 的可观测性不能靠"水位"，要靠"压力"。PSI 的 full 字段是内核给你的最诚实的"救火进度条"，把它接进 Prometheus 并配上 60s 的 for 窗口，是目前成本最低、误报率最低、提前量最稳定的 OOM 预警手段。

可复用清单：

[ ] 确认内核 ≥ 5.2 且 cgroup v2 已启用（stat -fc %T /sys/fs/cgroup/ 返回 cgroup2fs）
[ ] 确认 cadvisor ≥ 0.47，container_memory_pressure_full 指标已暴露
[ ] 告警规则：rate(container_memory_pressure_full_total[2m]) > 0.10 AND working_set > 80% * limit，for: 60s
[ ] 辅助规则：some - full > 0.5 持续 5min（单线程卡住场景）
[ ] 采集 memory.events 的 max 和 oom_kill 两个字段，区分"撑过去了"和"真 OOM 了"
[ ] 压测验证：用 8MB 循环分配的 Java 小程序，确认 full avg10 > 10 到 OOM 的间隔稳定在 20~30s
[ ] 把 PSI 告警的响应 SOP 写清楚：30 秒窗口内能做什么（扩 limit？降级？kill 线程？）

环境：K8s 1.28.9 / containerd 1.7.13 / ALinux 3 kernel 5.10.134-16 / Java 17 / cadvisor 0.49.1。文中 PSI 数值来自压测实录，阈值建议基于 6 周线上数据。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。