一、现象或背景：CPU 没打满，延迟却翻了 46 倍
我们一个 12 节点（8C16G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v1）的网关集群，跑着一个 Go 网关（单实例 4C limit / 1.5C request）。白天稳态 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/kubepods/podXXX/）
cat /sys/fs/cgroup/cpu/kubepods/podXXX/cpu.stat
输出示例：
# cgroup v1
cat /sys/fs/cgroup/cpu/kubepods/podXXX/cpu.stat
nr_periods 4820311
nr_throttled 283417
throttled_time 1987654321
throttling ratio ≈ 5.9%——每 17 个调度周期就有 1 个被卡住。Java 的 GC STW、线程池 burst、JIT 编译这些瞬间峰值操作，恰好撞在 CFS quota 的窗口边界上，被 throttle 了。
2）用 Prometheus 看 PSI 的 full stall：
rate(node_memory_pressure_full_seconds{pod=~".+"}[5m])
如果这个值持续上涨，说明你的服务在持续遭遇内存压力，而内存压力可能来源于 GC、大对象缓存或内存泄漏。
3）用 perf 看线程的调度状态：
perf record -g --call-graph dwarf -p <PID>
perf report
这个命令会记录线程的调度状态和 CPU 使用情况，帮助你定位哪些线程或函数在 CPU 被节流时表现异常。
四、踩过的坑或反直觉之处
-
CPU limit 是配额，不是天花板：很多人误以为 CPU limit 是一个硬性上限，但其实它只是每个调度周期内的配额，不会限制瞬时 CPU 使用。
-
平均 CPU 使用率不能说明节流严重性：即使 CPU 利用率只有 40%，如果节流严重，P99 依然可能大幅上涨。
-
P99 的毛刺可能来源于节流，而不是 GC、下游或连接池：很多团队在排查 P99 问题时，会优先检查 GC、下游或连接池，但实际上，节流才是更常见的原因。
五、结论与可复用清单
结论：K8s 的 CPU limit 是 cgroup 的配额，而不是 CPU 的上限。它会限制每个调度周期内 CPU 的使用总量，但不会限制瞬时 CPU 使用。因此，CPU limit 是一种「隐形性能税」，它会拉高 P99，但不会影响平均 CPU 使用率。
可复用清单：
- 使用
cat /sys/fs/cgroup/cpu/xxx/cpu.stat检查节流情况。 - 用 Prometheus 监控 PSI 的 full stall。
- 用
perf检查线程的调度状态。 - 不要把 CPU limit 当做 CPU 的上限，而是当成配额。
- 在设计 CPU limit 时，要结合业务的并发模式和 CPU 使用特征。
- P99 的毛刺可能来源于节流，而不是 GC、下游或连接池。
建议：在设置 CPU limit 时，要充分考虑业务的并发模式和 CPU 使用特征，避免设置过低的 limit 导致节流。同时，要结合监控和分析工具，及时发现和解决节流问题。