Linux线上CPU飙高排查流程

目标

线上 CPU 飙高时,最怕“边猜边改”。标准流程应该是先定位热点,再决定是否限流、降级、回滚。

第一步:确认是系统级还是进程级

先看整体:

top
mpstat -P ALL 1
uptime

关注点:

  • load average 是否持续升高
  • us/sys/wa 哪一项异常
  • 是否是单核打满还是多核普遍升高

第二步:定位异常进程

top -Hp <pid>
ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head

先抓出 Top 进程,再看该进程内哪个线程最热。

第三步:线程级定位到代码

Java 服务

  1. top -Hp 找线程 TID。
  2. 十进制转十六进制:printf '%x\n' <tid>
  3. jstack <pid> | grep -A 30 <hex_tid> 定位堆栈。

Go 服务

  • curl /debug/pprof/profile?seconds=30
  • go tool pprof 看热点函数。

C/C++ 服务

  • perf top -p <pid>
  • perf record -g -p <pid>perf report

第四步:判断故障类型

常见类型:

  • 死循环或高频重试
  • 锁竞争导致忙等
  • 大量短周期任务抢占
  • 异常流量触发复杂路径
  • GC 频繁触发

第五步:先止血再修复

可选止血策略:

  • 网关限流
  • 关闭高成本功能开关
  • 扩容副本分摊压力
  • 回滚可疑版本

止血后再进入根因修复,避免故障扩大。

取证材料清单

故障当下必须保存:

  • Top 进程快照
  • 线程栈/pprof/perf 数据
  • 入口流量和错误率曲线
  • 最近发布记录与配置变更

这些材料决定你是否能在复盘中给出可执行结论。

复盘模板

  • 触发条件是什么
  • 为什么监控没有提前告警
  • 为什么自动保护没生效
  • 哪个改动能永久避免复发

总结

CPU 故障处理的核心是“证据链”。先定位、再止血、后修复,避免凭经验拍脑袋。

results matching ""

    No results matching ""

    results matching ""

      No results matching ""