CPU使用率看起来不高，应用却突然变慢，未必是程序出了故障。判断共享CPU实例突发性能受限的判断方法，关键是把负载、实例指标和延迟放在同一时间线上核对。不同云平台机制并不相同：有的实例采用CPU积分，有的按共享核数或配额调度，不能只凭一个指标下结论。
年度十大检查要点
- 核对实例规格。记录实例型号、vCPU数量及共享或突发说明，确认是否存在基准CPU性能、积分余额或持续使用上限。更换规格或计费模式后，也要重新确认规则。
- 看CPU使用率是否持续贴近上限。检查监控平台的CPU利用率，重点关注性能下降前后的连续区间，而非单个采样点。短时峰值可能正常；长时间高负载更可能是容量不足。
- 查积分或突发余额。以AWS EC2 T系列为例，适用型号可查看CPU积分相关指标，如CPU积分余额及使用量；具体指标名称和含义应以实例型号、监控配置及平台文档为准。余额下降并与延迟上升同步，是重要线索，但不适用于所有共享实例。
- 确认是否触发配额或限流。查看云平台的实例监控、事件记录和限速指标。若CPU用量在某一水平附近反复被压住，同时请求变慢，可能是配额约束；不能把网络带宽或磁盘限流误认成CPU受限。
- 观察运行队列与调度等待。在Linux系统上，可用vmstat观察运行队列和CPU等待情况，用top查看进程及CPU状态。容器环境还应核对CPU请求、限制值和节流统计；这些指标需结合具体内核、容器运行时解释。
- 把延迟和错误率对齐。同时查看接口响应时间、超时率、任务完成时间与CPU指标。若延迟变化早于CPU异常，或只影响单个接口，应优先排查应用和依赖服务。
- 拆分进程与线程负载。找出占用CPU最多的进程，检查单线程是否跑满。多核实例的总CPU利用率不高，不代表单个关键线程没有成为瓶颈。
- 排除内存、磁盘和网络问题。检查内存压力、交换活动、磁盘延迟及网络丢包。数据库查询变慢、磁盘队列变长或外部服务响应迟缓，都可能造成类似“CPU不够用”的表象。
- 对比相同负载时段。比较工作日与低峰期、批处理开始前后，以及扩容或发布前后的指标。注意采样间隔和时区一致，避免把不同负载条件下的数据直接比较。
- 做可回退的验证。在维护窗口或低风险副本上，短时降低并发，或换用更高基准性能的规格进行对照。若负载相近时延迟明显改善，且CPU限制信号消失，才更支持突发性能受限的判断；测试后记录配置并按计划恢复。
怎样区分限流与其他瓶颈
CPU积分耗尽、配额触顶或调度争用，往往表现为CPU相关限制信号与性能下降同时出现。应用自身计算量过大，则常能定位到具体进程或线程；磁盘、网络和内存瓶颈通常会在各自指标上留下对应变化。共享宿主机可能带来波动，但单次延迟升高不足以证明宿主机争用，最好结合平台事件和多时段趋势。
实际排查时，先确认实例规则，再对齐CPU、限流、应用延迟和资源指标；随后用低风险对照验证。这样使用共享CPU实例突发性能受限的判断方法，能避免把偶发峰值直接等同于实例受限。
常见问题
CPU利用率不高，也可能受限吗？
可能。单线程瓶颈、CPU配额或积分机制都可能让总利用率未达100%；应继续检查线程负载和平台限制指标。
CPU积分余额低就一定会变慢吗？
不一定。影响取决于实例型号、运行模式和平台规则，应同时观察积分变化、CPU使用及应用延迟。
应该先升级实例还是先优化程序？
若计算热点明确，先评估优化收益；若持续负载超过实例基准且限制信号吻合，可测试更高基准性能规格，再比较成本与延迟。
需要观察多久？
至少覆盖一次性能异常及其前后变化；对于周期性任务，还应覆盖完整业务周期。具体时长取决于监控采样间隔和负载规律。