cgroup v2 memory.high 软压力：把 K8s Pod 延迟从 40ms 推到 220ms 的隐形杀手

作者苏砚舟-103

cgroup-v2Kubernetesmemory性能排查SRE

一、现象：RSS 没到 limit，P99 却从 40ms 涨到 220ms

上个月（10 月），线上一个 Java 17 服务（Spring Boot 3.2.5，K8s 1.28.9 + cgroup v2，单 Pod 4C/2Gi），白天 QPS 稳定在 800 左右。某天 14:30 开始，P50 稳定在 12ms，P99 却从常态的 40ms 涨到 220ms，持续约 20 分钟，之后自己恢复。

关键矛盾：整个窗口里 RSS 最高只到 1.72Gi，离 memory.limit=2Gi 还有 14% 余量；dmesg 没有 OOM、没有 page allocation failure；JVM GC 日志里没有长 STW（最长一次 Young GC 28ms）。按"内存没爆、GC 没卡"的直觉，团队一度怀疑是下游抖动，折腾了 40 分钟没结论。

二、原理：cgroup v2 的 memory.high 是"软压力阀"，不是"软上限"

K8s 1.27 起在主流发行版（RHEL 9、Ubuntu 22.04+、Debian 12）默认切到 cgroup v2。v2 比 v1 多了一个 memory.high 文件：

memory.max：硬上限，超了直接 OOM（等价 K8s 的 memory.limit）；
memory.high：软压力阈值，一旦 memory.current 摸到它，内核会主动发起 reclaim——包括：
1. 直接回收（direct reclaim）：把 cgroup 内 LRU inactive 链的页推到 swap / page cache 驱逐；
2. 唤醒 kswapd 异步回收；
3. 关键：这个 reclaim 发生在分配路径上，也就是 malloc / mmap 的调用栈里，JVM 完全看不到，GC 日志里没有任何痕迹。

而 K8s 本身不会主动写 memory.high——它只写 memory.max。但以下场景会写：

你用了某些"内存节流"的 DaemonSet / Operator（比如某些 sidecar 注入器）；
节点上跑着自研的"内存保护"agent，看到 cgroup 水位高就写 high；
你自己 kubectl exec 进去做过实验，忘了恢复。

这次事故的真凶就是第三种：一周前一次压测，有人 echo 1879048192 > memory.high（=1.75Gi，故意留 10% 余量），压测完没清。此后每次 RSS 摸到 1.75Gi，内核就开始 direct reclaim，单次 reclaim 耗时 3~15ms，频率约每 200ms 一次——对 JVM 来说就是"每次 malloc 都可能被卡一下"，P99 直接被打穿。

三、具体做法：3 条命令定位 + 1 个修复动作

A. 看 memory.high 是否被写过（默认应为 "max"）

kubectl exec -it <pod> -- sh -c \
  'cat /sys/fs/cgroup/memory.high; echo ---; cat /sys/fs/cgroup/memory.current; echo ---; cat /sys/fs/cgroup/memory.max'

判据：memory.high 是 max = 没被写过；是一个具体字节数 = 有人写过，这就是嫌疑人。

B. 看内核是否在做 direct reclaim（/proc/meminfo 不够，要看 cgroup 计数）

kubectl exec -it <pod> -- sh -c '
  cat /sys/fs/cgroup/memory.events
  cat /sys/fs/cgroup/memory.stat | grep -E "^(pgrefill|pgsteal|workingset_refault) "
'

判据：workingset_refault 在事故窗口内快速增长（每秒 +1000 以上）= 内核在反复把刚用过的页又换回来 = soft pressure 实锤。

C. 看 JVM 侧是否感知到（其实感知不到，这是反直觉点）

# GC 日志里看不到 direct reclaim，但能看到"malloc 变慢"
# 用 async-profiler 抓 10s 火焰图，看 java 侧是否卡在 native 层
async-profiler -d 10 -e alloc -f /tmp/alloc.html <pid>
# 火焰图里如果出现大量 "malloc -> page fault -> direct_reclaim" 的栈，就是它

修复动作（一行命令）

kubectl exec -it <pod> -- sh -c 'echo max > /sys/fs/cgroup/memory.high'

执行后 10 秒内 P99 从 220ms 回落到 41ms，workingset_refault 增速归零。

四、踩过的坑：3 个反直觉点

坑 1：监控里"内存使用率"是假的 Prometheus 的 container_memory_working_set_bytes 只读 RSS + page cache（不含 swap），看起来"才 86%"，但内核已经在做 reclaim。正确指标是 memory.current / memory.high，这个比值 > 0.95 就该告警。

坑 2：JVM 完全不知道自己被"动过" direct reclaim 发生在内核态，JVM 的 GC、-Xmx、-XX:MaxRAMPercentage 全都正常。你以为"JVM 没爆"，其实是"内核在帮你做 GC，只是没打招呼"。

坑 3：cgroup v1 没有这个坑，v2 才有 v1 的 memory.limit_in_bytes 是硬上限，没有 soft 这一档；v2 把 soft/hard 拆成两个文件，这是 v2 的"新特性"，也是 v2 的"新坑"。从 v1 迁 v2 的团队要专门审一遍"谁写过 memory.high"。

五、结论与可复用清单

结论：cgroup v2 的 memory.high 是一个默认无人写、但一旦被写就会静默拖慢应用的隐藏旋钮。K8s 不帮你管它，你得自己管。

可复用清单（贴到值班手册）：

上线前：grep -r memory.high /sys/fs/cgroup/ 全节点扫一遍，确认没被写过；
监控：Prometheus 加 memory.current / memory.high 比值告警（> 0.9 黄色，> 0.95 红色）；
排查：P99 抖动但 OOM/GC 都正常时，第一时间 cat memory.high 和 memory.events，10 秒出结论；
治理：写一份"谁可以写 memory.high"的 SOP，压测后必须 echo max > memory.high 复位；
长期：考虑把 memory.high 显式设为 limit 的 95%（memory.high = memory.max * 0.95），主动让内核提前 reclaim，避免一次性摸到 hard limit 触发 OOM——这是 v2 的正确用法，前提是你要主动、可控、可观测地用它，而不是被动挨打。

一句话：cgroup v2 给了你软压力阀，但你不开阀就让它关着；开了阀就要盯着它。

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

暂无评论。