平均 CPU 利用率指标为何该摒弃？多个案例揭示真相！

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 的反应堆称此为“反应堆停滞”11CockroachDB 围绕 Go 的 /sched/latencies:seconds 直方图构建反馈控制器p99 延迟超 1 毫秒触发减少后台工作 12。Go 1.25 默认使 GOMAXPROCS 支持 cgroup13可降低资源饥饿风险但同一容器内其他进程耗尽共享预算时无能为力所以应用程序层面检测仍是通用解决方案。6. 总结为 Docker 容器设置资源限制是分配时间预算资源密集型 HTTP 请求可能瞬间耗尽节点核心资源平均 CPU 图表可能无法反映情况。应关注 cgroup 限流、内核 PSI、虚拟机管理程序窃取时间、应用程序层面资源饥饿信号等指标。综合使用这些指标可发现平均 CPU 图表隐藏的问题。在大型组织运行应用程序时因资源限制问题请求增加 CPU 或取消限制可能遭 IT 部门拒绝他们会提及审计和合规性指南。所以应摒弃平均 CPU 利用率指标而非取消资源限制可提供更多信息处理限制。若遇到类似讨论可分享此文章。