Linux 服务器 CPU 飙高排查：从 load average 到线程级定位

背景

云服务器 CPU 告警是最常见的运维事件之一。同样是 CPU 高，原因可能是业务线程死循环、GC 频繁、大量系统调用，也可能是 IO 等待把 load 拉高。本文给出一套从宏观到微观的排查流程，命令均可在 CVM、轻量应用服务器上直接执行。

1. 先区分 load 与 CPU 使用率

load average 统计的是处于运行队列和不可中断睡眠（D 状态）的任务数，并不等于 CPU 使用率。

uptime
# 10:20:01 up 36 days, load average: 8.12, 6.90, 5.31
nproc

• load 明显大于核数：存在排队，可能是 CPU 饱和，也可能是大量 D 状态进程（磁盘/NFS 卡住）。
• 1、5、15 分钟三个值递增还是递减，可判断问题在恶化还是在恢复。

2. 看 CPU 时间构成

top -b -n 1 | head -n 15
vmstat 1 5

重点看各列占比：

• us 高：用户态计算，多半是业务代码。
• sy 高：系统调用或上下文切换过多，常见于锁竞争、频繁小 IO。
• wa 高：等待磁盘，应转向 iostat -x 1 排查 IO。
• st 高：宿主机资源争抢，需要联系云厂商或更换实例规格，应用侧无法解决。

3. 定位到进程与线程

ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -n 10
top -H -p <PID>

top -H 会按线程展示 CPU。拿到最高的线程 ID（TID）后，转十六进制，便于在线程栈中对照：

printf '%x\n' <TID>

4. 抓取线程栈

Java 进程：

jstack <PID> | grep -A 20 "nid=0x<十六进制TID>"

如果发现大量 GC 线程占用 CPU，应转看 jstat -gcutil <PID> 1000，检查老年代是否持续接近满。

非 JVM 进程可以用 perf：

perf top -p <PID>
perf record -g -p <PID> -- sleep 30
perf report

strace -c -p <PID> 可以统计系统调用耗时分布，sy 高时很有用，但对线上进程有性能影响，应限定时间使用。

5. 常见原因与处理

6. 注意事项

• 排查前先保留现场（top、栈、perf 数据），再重启服务，否则无法复盘。
• 云监控的 CPU 告警建议设置“持续多个周期”触发，避免瞬时毛刺造成误报。
• 具体告警配置入口与指标名称以腾讯云控制台为准。

总结

排查顺序：load → CPU 构成 → 进程 → 线程 → 栈/perf → 归因。每一步都用数据缩小范围，比直接重启更可靠，也能为后续优化留下证据。