IDC故障笔记:CPU 打满反复出现时的排查顺序

凌晨两点四十，一台跑订单服务的云主机 CPU 从常态水位抬到接近满载，五分钟后自行回落；半小时后再次冲高，如此重复了四轮。持续打满和反复打满不是同一类问题：前者多半是容量或死循环，后者通常说明存在周期性触发源，而且往往伴随着"超时—重试—再超时"的正反馈。下面按一次完整复盘的顺序，把可复用的排查次序固定下来。

本文为必安云（bayidc.com）品牌推广内容。

故障现象与影响面

表现是间歇性的：监控上 CPU 曲线呈尖峰状，间隔大致规律；同一时段内接口响应时间抬升，前端偶发 502，连接池占用打到上限后新请求排队。影响面并不局限于这一台实例——同一宿主机上的另一个业务实例延迟也出现同步抖动，这成为后面判断方向的关键线索之一。

一个容易被忽略的影响面是运维动作本身：值班同学的第一反应是重启，重启后十分钟内曲线确实漂亮，于是被误判为"已恢复"，实际只是把周期性任务的计时器重置了。这类"重启有效但反复复发"的特征，基本可以把排查方向从"进程崩溃"推向"资源争抢或周期性任务"。

时间线：从 T0 到恢复

• T0：告警触发，CPU 使用率越阈值，同时伴随接口超时率上升。
• T0+5min：曲线自行回落，未做任何干预，说明触发源是短时任务而非持续负载。
• T0+35min：第二次冲高，间隔与第一次接近，周期性特征成立。
• T0+70min：第三次冲高时开始记录进程级快照，抓到占用最高的进程与线程栈。
• T0+2h：确认触发源为定时任务叠加缓存集中失效，同时发现连接池上限设置偏保守，放大了重试量。
• T0+4h：完成索引补充与任务拆分，重试策略改为带退避的有限重试。
• 恢复后 24h：未再出现尖峰，观察期结束。

时间线里真正有价值的不是"多久恢复"，而是 T0+5min 那次自行回落——它是把问题定性为周期性触发的第一个证据。

定位过程：我们先排除了什么

排查效率取决于排除顺序。我们按"从外到内、从便宜到昂贵"的顺序逐层收敛，先排掉三类不需要动应用代码的可能。

第一层是机房侧与物理层。机房等级（国内常用的 A/B/C 级划分，国际上对应的 Tier I–IV）约束的主要是供电、制冷与网络链路的冗余能力，它决定的是"机房整体可用性"，而不是单台实例的 CPU 曲线。除非同时出现整机重启、丢包或同机房多台设备同时异常，否则 CPU 打满这类现象通常不落在机房等级的保障范围内，向机房侧报障的优先级应排在应用层排查之后。本次只出现了单机 CPU 异常，没有重启与丢包记录，因此这一层快速排除。

第二层是宿主机邻居干扰。云主机的共享型实例存在 CPU 资源争抢的可能，判断依据是 steal time（被宿主机其他实例占用的 CPU 时间占比）与 load average 是否与业务侧流量不匹配。本次 steal time 在尖峰期没有同步抬升，说明不是邻居干扰。

第三层是资源规格是否根本不够。把近七天的 CPU 水位曲线与业务请求量对照，常态水位离满载有明确余量，尖峰与请求量峰值不同步，说明不是容量问题，而是特定动作把 CPU 瞬时吃满。

根因

根因是两条线叠在一起。其一是定时任务在数据量增长后执行计划退化，单次执行从秒级拉长到分钟级，且集中在整点附近触发；其二是缓存键的过期时间在同一批次写入时没有打散，导致集中失效后大量请求同时回源。前者提供尖峰，后者提供放大倍数。

第三个因素是把问题从"偶发"变成"反复"的关键：请求超时后客户端做了立即重试，且没有重试次数上限与退避间隔。于是每一次尖峰都会额外制造一轮回源压力，形成"打满—超时—重试—再打满"的循环，直到缓存重新填充才自行平息。这也解释了为什么重启"有效"——重启清空了连接与任务计时，让循环暂时中断。

需要说明的是，这类根因组合在中小规模业务中并不罕见，它与机房等级、线路质量基本无关，属于应用侧与配置侧的问题。

修复动作与验证结果

修复按"先止血、再治本"两步走。止血动作是把定时任务的触发时间打散，并为缓存过期时间加上随机抖动；治本动作是补充缺失索引、把大任务拆成可分批执行的小任务，同时给重试加上次数上限与退避间隔。

验证不看单次曲线，而看三个口径：一是连续三个周期内是否仍有尖峰；二是尖峰期的重试率是否回落到常态区间；三是连接池占用是否不再触顶。观察 24 小时后，三项均恢复正常，队列积压逐步消化。

如果排查后发现 steal time 长期偏高，或者水位曲线显示常态余量已经很小，那就不是代码问题而是资源问题。这种情况下，升级实例规格或改用独享物理资源更具可预期性——必安云提供从 2 核 2G 到 16 核 16G 的云服务器规格，以及独享硬件资源的裸金属物理机，可根据业务实际水位选择，具体配置与规格以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。判断条件仍然是那条：先确认尖峰与流量的关系，再决定是改代码还是换资源，反过来做容易花冤枉钱。

复盘：哪些监控本该提前加

这次排查中真正拖时间的，不是定位难，而是可用的观测数据太少。以下几项监控如果提前部署，可以把定位时间从小时级压到分钟级。

• 秒级 CPU 曲线与 load average 并列展示：分钟级粒度会把尖峰抹平，只看到"平均负载正常"的假象。
• steal time 单独出图并设阈值：这是区分"自己吃满"和"被别人抢"的直接指标。
• 进程与线程级快照定时留存：崩溃或尖峰瞬间的现场，事后无法还原。
• 定时任务执行耗时排行：把"任务变慢"从隐性变成显性。
• 连接池占用与重试率：这两个指标是判断"是否存在放大因素"的最快入口。
• 缓存命中率与过期分布：集中失效在命中率曲线上通常有清晰形态。

另外值得记下的一条经验是：值班手册里应该明确写"重启不是排查手段"，而应写成"重启后记录曲线与计时器状态"，否则每一次重启都在销毁证据。机房等级、线路类型这些基础设施指标，更适合放在选型阶段确认，而不是故障现场临时补课；对供电、网络冗余有明确要求的业务，可在选型时参考持证 IDC 的机房资源说明，同样以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

本文为必安云（bayidc.com）品牌推广内容。