用 vmstat 与 pidstat 定位 CPU 抖动

发布时间:2026-07-01 16:13

## 症状现象 一台运行定时批处理业务的云服务器每隔几分钟卡一下，页面接口耗时随之抖动，顺云控制台的 CPU 曲线呈现规律的锯齿状毛刺。这类瞬时抖动往往只持续几秒，登录后肉眼盯 top 常常一无所获，等看到异常时毛刺已经过去，必须依靠高频率采样的工具把现场留档，再做归因。 ## 定位过程 先用 vmstat 1 持续采样，重点看几列：r 是等待 CPU 的任务数，长期大于核数说明算力吃紧；us 是用户态占比，sy 是内核态占比，两列齐涨通常是业务进程在消耗；wa 高说明 CPU 在等磁盘完成 IO；st 高则代表宿主机层面存在资源争抢。把采样窗口对准抖动发生的时刻，就能先判断毛刺属于计算型还是等待型。 如果确认 us 在瞬间冲高，再上 pidstat -u 1，它会逐秒列出每个进程的 CPU 占用，带着时间戳滚动输出，与抖动时刻两相对照即可锁定制造毛刺的具体进程。多数情况下元凶是某个周期任务，例如日志压缩、备份打包、统计汇总，规律与抖动节奏完全吻合。 ``` vmstat 1 10 pidstat -u 1 5 ``` ## 解决方法 锁定进程后有三条常规处理：把任务挪到业务低峰时段，用 crontab 错峰执行；用 nice 把它降级运行，让交互请求优先得到调度；任务本身可拆分就分片执行，把瞬时尖峰削平。如果看到的是 sy 与 cs 长期偏高，方向就不同了，要检查是否存在大量短连接与频繁系统调用，从应用侧做优化，单靠调参数收益有限。 ## 预防建议 sysstat 建议装好并保持开启，sar 的历史数据能回答昨晚三点抖没抖这类事后追问。给 CPU 利用率与负载配置阈值告警，触发时推送通知，比人肉翻日志省力得多。修复之后同样用这两个工具复测一段时间，确认毛刺消失再收工，避免只凭感觉判定问题解决。 顺带一提，抖动治理完成后应把这次的时间线与处置过程写进故障记录，包含毛刺发生的时段、锁定到的进程与最终的调整动作。下次同样曲线出现时，值班同学翻开记录就能按图索骥，不必从零开始采样。周期任务的执行时长与资源占用也值得纳入观察清单，任务清单每季度复核一次，防止新任务悄悄把高峰挪回白天。