CPU limit 不是上限而是配额：CFS 节流让 P99 长尾翻 5 倍的复盘与排查

作者苏砚舟-103

KubernetesCFSCPU limitP99cgroup性能调优

一、现象：P50 稳如老狗，P99 却间歇性飙到 5 倍

先给结论：这次 P99 长尾的根因不是 GC、不是下游、不是连接池，而是我们给容器设的 cpu.limit=1.5 触发了 Linux CFS 的周期性硬切（throttling）。容器里 CPU 利用率长期只有 35%~45%，监控一片绿，但 P99 每隔几十秒就飙一波，最严重的一次 P50=8ms 的同时 P99=41ms，持续约 40 秒。

场景很典型：一个 Go 写的高并发网关，Kubernetes 1.28.9 + containerd 1.7，单 Pod 4C 节点上跑，resources.limits.cpu: "1500"（即 1.5 核）、requests.cpu: "500"。QPS 稳定在 1200 左右，没有压测、没有发布，纯粹是白天某个时段开始抖。因为 top 里 CPU 占用才 40%，团队一度把方向全押在「慢 SQL」「下游超时」上，折腾了两天。

二、原理：limit 是"配额"，不是"天花板"

关键认知：K8s 的 cpu.limit 在底层翻译成 cgroup 的 cpu.cfs_quota_us / cpu.cfs_period_us，它不限制瞬时能跑多快，而是限制"每个 period 内最多能用多少 CPU 时间"。

cpu.cfs_period_us 默认 100ms（100000us）；
cpu.cfs_quota_us = limit × period，1.5 核就是 1500 × 100ms = 150ms。

也就是说：在这 100ms 周期里，所有线程加起来最多只能用 150ms 的 CPU 时间。如果你的进程有 4 个线程想同时满核跑，它们合计需要 400ms，但配额只有 150ms，于是内核直接把整个 cgroup 切走（throttle），直到下一个 period 才放行。这就是为什么 CPU 占用"看起来不高"，却会被卡住——占用率是平均值，节流是瞬时硬切，两者根本不在一个量纲上。

Go 网关里 http.Server 的 goroutine 跑在多个 OS 线程（GOMAXPROCS 默认=4）上，一旦某 100ms 内并发请求密集，4 个线程齐抢 CPU，瞬间就把 150ms 配额耗尽，整组线程被冻结 50ms+，请求直接在队列里排队——表现出来就是 P99 周期性毛刺，而不是 P50 上涨。

三、具体做法：3 条命令把"隐形节流"揪出来

1）直接看 cgroup 的节流统计（这是最硬的证据）：

# 找到该容器所在的 cgroup v1/v2 路径（containerd 一般是 /sys/fs/cgroup/cpu/.../<container-id>）
cat /sys/fs/cgroup/cpu/cpu.stat
# 重点看两行：
# nr_throttled      被节流的周期数
# throttled_time    累计被冻结的纳秒数

我当时的输出是 nr_throttled 在 60 秒内从 0 涨到 217，throttled_time 涨了约 9.6s（纳秒）——9.6 秒的冻结，正好对应那 40 秒窗口里一波波 P99 毛刺。这是决定性的：CPU 不高，但被切走了 9.6 秒。

2）Prometheus 持续监控（把节流变成常态指标，别等出事再翻 cgroup）：

# 节流比例：被节流的周期数 / 总周期数，> 0.1 就该警惕
rate(container_cpu_cfs_throttled_periods_total{pod=~"gw-.*"}[1m])
/
rate(container_cpu_cfs_periods_total{pod=~"gw-.*"}[1m])

3）验证性调参（确认是它之后，两条路）：

# 方案 A：放开 limit，保留 request 做调度
resources:
  requests:
    cpu: "1500"
    memory: "2Gi"
  limits:
    memory: "2Gi"
    # cpu: 故意不写 —— 让它用满节点空闲 CPU，避免硬切

# 方案 B：确实要限流时，把 limit 调高到"峰值并发 × 线程数"的量级
# 我们最终是 1.5 -> 3.0，P99 立刻回落到 9~11ms
resources:
  limits:
    cpu: "3000"

调整后 10 分钟内 P99 从 41ms 回落到 11ms，nr_throttled 增速降到几乎为 0。关键不是"去掉 limit"，而是让 quota 覆盖真实峰值并发——1.5 核的平均占用没问题，但盖不住 4 线程齐抢的瞬时峰值。

四、踩过的坑（反直觉的地方）

top / htop 的 CPU% 是"平均"视角，对节流完全失明。 一个被冻结 50ms 的容器，平均下来占用率可能才 40%，看着非常健康。必须看 throttled_time / nr_throttled 这两个累计量。
"limit 没设很高"不是安全信号。 1.5 核听起来很宽松，但对 4 线程高并发服务，峰值需求能到 4 核。limit 设得比"平均需求"高、比"峰值需求"低，恰恰是最容易触节流的区间。
request 和 limit 拉得越近，越容易被调度器塞到同一节点后互相挤。 我们 request=0.5 / limit=1.5，调度只按 0.5 算，节点上挤了一堆"0.5 请求"的 Pod，实际一起跑时 CPU 争抢比预期激烈得多。
GC / 日志刷盘这类"突发 CPU 事件"是节流的放大器。 一次 GC 或一次批量序列化，瞬时把 quota 打光，把本来 1ms 的延迟拖成几十 ms——它把"偶发抖动"放大成"周期长尾"。

五、结论与可复用清单

一句话：CPU limit 是"周期性配额"，不是"性能天花板"；它不让你变慢，而是让你在峰值时"被冻结"，最终表现为 P99 长尾。

可复用清单（直接抄）：

[ ] 监控面板必须加 container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total 的比率，>0.1 告警；
[ ] 排查 P99 长尾时，先 cat cpu.stat 看 nr_throttled / throttled_time，再怀疑下游；
[ ] 给高并发多线程服务设 CPU limit 时，按 峰值并发线程数 × 单线程需求 估，而不是按平均占用；
[ ] 能不设 CPU limit 就不设（尤其 Go/Java 这类多核服务），用 request 做调度、靠节点隔离做边界；
[ ] request 与 limit 别贴太近，避免调度器把"低请求高 limit"的 Pod 密集堆叠；
[ ] 区分两种问题：平均占用高（真资源不够）vs 占用不高但被节流（配额/并发不匹配），两者解法完全不同。

这套排查思路对 GC 毛刺、慢 SQL 之外的"第三种 P99 凶手"特别有用——它不占 CPU、不报错误、不连不上，只是安静地把你冻结了 50 毫秒，然后你的 P99 就交代了。

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

暂无评论。