1. 作者信息与文章背景
Jeremy Theocharis 是《平凡即卓越》作者、UMH 联合创始人兼首席技术官。文章基于其在 2026 年 4 月云原生亚琛聚会上的演讲，探讨为何应摒弃平均 CPU 利用率指标。
2. 应用程序问题引出
我们应用程序中的一个 Go 函数在生产环境总是被取消执行。该函数设置严格超时时间，同样代码在开发环境、CI/CD 管道及集成测试中正常运行，但在生产环境有时超超时时间，以 `context deadline exceeded` 错误终止。更糟的是，使用的状态机库 1 在上下文被取消后无法自行恢复，会崩溃并挂起，且无法复现问题。与用户交流，他们反馈 CPU 利用率正常，我们花数周才找到问题根源。
3. 为何平均 CPU 指标不够用
从事计算机工作，系统变慢时，常打开任务管理器查看 CPU 情况。在 Linux 服务器可用 `top`、`htop` 等工具，我们常关注平均 CPU 使用率。配置虚拟机时，会选 vCPU 数量，有“高性能”“专用”等昂贵选项，但我们可能未探究原因。然而，各种工具、供应商和仪表盘传达的直觉在这里失灵。所有工具只显示平均 CPU 利用率，无法帮助解读该指标。CPU 利用率与可用容量非线性关系，从 80% 到 81% 的 CPU 利用率提升增加的等待时间，约是从 10% 到 11% 提升的 20 倍 2。即使 80% 利用率下有 20%“余量”，延迟也已开始上升 3。平均 CPU 利用率适用于判断 CPU 是否有效利用，是成本问题，但仅适用于可等待的工作负载。对于对延迟敏感的工作负载，更高利用率意味着更长等待时间。在我们案例中，CPU 利用率不高，遇到 Linux 内核 `cgroup` 特性及限流副作用。容器设置资源限制为 `2000m`，内核视为时间预算，预算耗尽容器会被 `限流`，直到下一个周期开始。我们和客户使用的工具未显示此问题，所以花数周才找到 `context deadline exceeded` 错误原因。
4. CFS 限流的实际工作原理
假设在容器运行处理 HTTP 消息的服务，按指南设置资源限制 4。`kubectl top pod` 显示使用 800 毫核，水平 Pod 自动伸缩器（HPA）配置为 80% 利用率时扩容，2000m 限制下使用 800m 仅 40%，看似正常。但实际有三个关键数字决定情况：资源限制 `2000m`、内核的 CFS 调度周期默认 100 毫秒 5、主机 CPU `4 核`。容器可在节点所有 CPU 核心分配 200 毫秒时间。一个资源密集型 HTTP 请求可能 50 毫秒耗尽 `4 核` 可用预算，第二个请求会被 `限流`，需等 50 毫秒到下一个调度周期。若负载模式是“突发、空闲、空闲、空闲、突发”，p99 延迟可能急剧上升，但 CPU 图表仍显示正常。我们的 Go 函数就遇到此问题，因其他 goroutine 耗尽周期可用预算，函数因资源不足终止，出现 `context deadline exceeded` 错误，且底层库 1 上下文被取消时会陷入死锁，CPU 图表却显示正常。Indeed Engineering 在 2019 年也发布类似案例 6。
5. 如何发现并应对该问题
我们花数周找错方向，其实所需指标在 `/sys/fs/cgroup/cpu.stat` 中 7。内核为设置 CPU 限制的容器记录 `nr_throttled` 和 `throttled_usec`。运行 `kubectl exec -- cat /sys/fs/cgroup/cpu.stat` 可查看。若计数器增加，说明有问题。在相关生态系统完善前，需自己检查指标。Kube - prometheus 提供 `CPUThrottlingHigh` 警报，但大多安装禁用，因常误报 8。对于专用核心容器，可通过 `cat /sys/fs/cgroup/cpu.stat` 检查，同一目录的 `cpu.pressure` 可检测资源饱和 9。对于虚拟机 vCPU，可通过 `top` 中 `%st` 查看“窃取时间”10。即时解决方法是检查这些指标，长远需在应用程序层面进行资源饥饿检测。应用程序可检查一毫秒是否正常，若不正常说明 CPU 资源不足，可能是 CFS 限流、虚拟机窃取时间等原因。应用程序应发出警报并反应，如推迟后台维护工作。Redpanda 的反应堆称此为“反应堆停滞”11，CockroachDB 围绕 Go 的 `/sched/latencies:seconds` 直方图构建反馈控制器，p99 延迟超 1 毫秒触发减少后台工作 12。Go 1.25 默认使 `GOMAXPROCS` 支持 cgroup13，可降低资源饥饿风险，但同一容器内其他进程耗尽共享预算时无能为力，所以应用程序层面检测仍是通用解决方案。
6. 总结
为 Docker 容器设置资源限制，是分配时间预算，资源密集型 HTTP 请求可能瞬间耗尽节点核心资源，平均 CPU 图表可能无法反映情况。应关注 `cgroup` 限流、内核 PSI、虚拟机管理程序窃取时间、应用程序层面资源饥饿信号等指标。综合使用这些指标，可发现平均 CPU 图表隐藏的问题。在大型组织运行应用程序时，因资源限制问题请求增加 CPU 或取消限制，可能遭 IT 部门拒绝，他们会提及审计和合规性指南。所以应摒弃平均 CPU 利用率指标，而非取消资源限制，可提供更多信息处理限制。若遇到类似讨论，可分享此文章。
