Linux 服务器 CPU 飙高排查：一套实战定位思路

CPU 问题排查的核心链路：先分层，再深入；先分态，再取证；先保现场，再做动作。 整机 → 进程 → 线程 → 调用栈，顺着四层往下走，判断不会跑偏。

一、快速诊断三问

二、整机级判断（先别急着动）

# 一轮命令固定现场
date && hostname -f && uptime
w
top -b -n 1 | head -20
mpstat -P ALL 1 3
vmstat 1 5
sar -u 1 5
sar -q 1 5
free -h
df -h
dmesg -T | tail -50

关键指标解读：

三、用户态 vs 系统态

区分方向

%sys 高 → 继续定位

cat /proc/softirqs
cat /proc/interrupts
sar -n DEV,EDEV 1 5
ethtool -S eth0 | egrep 'drop|miss|error|timeout'

%usr 高 → 进入进程/线程定位

四、进程级定位

# 找 CPU 高的进程
ps -eo pid,ppid,lstart,etime,pcpu,pmem,cmd --sort=-pcpu | head -20

# 看进程周期性 CPU 走势
pidstat -u -t -p <PID> 1 5

# 看进程打开的文件描述符
lsof -p <PID> | head -50

不同语言排查路径

实战判断点

• 新拉起的进程 CPU 高 → 新版本发布、配置变更、缓存未热
• 运行几天后的进程 CPU 高 → 线程泄漏、连接泄漏、任务堆积、GC 退化
• 只有某个工作线程高 → 优先抓线程栈，不要先抓完整堆 dump

五、线程级定位（最有价值的一步）

# 查看进程内线程 CPU
top -H -p <PID>
ps -Lp <PID> -o pid,tid,psr,pcpu,stat,comm --sort=-pcpu | head -20
pidstat -t -p <PID> 1 5

# perf 热点采样（比 strace 更适合 CPU 分析）
sudo perf top -p <PID> -g # 实时查看
sudo perf record -F 99 -p <PID> -g -- sleep 30 # 采样留存
sudo perf report --stdio | head -80 # 查看热点函数

六、系统态 CPU 高：中断/网络/磁盘

排查顺序：网卡收发 → 软中断分布 → 连接状态 → 磁盘队列 → 内核日志

sar -n DEV,EDEV,TCP,ETCP 1 5
ss -s
ss -ant state syn-recv
netstat -s | egrep -i 'listen|overflow|drop|retrans'
cat /proc/softirqs
cat /proc/net/softnet_stat
iostat -xz 1 5
pidstat -d 1 5

七、云主机/容器特殊检查

# 宿主机抢占
mpstat -P ALL 1 5 # 看 %steal

# 容器 CPU 节流
grep . /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu.stat 2>/dev/null

# K8s 视角
kubectl top node
kubectl top pod -A --containers | head -30
kubectl describe node <name> | egrep -A3 'Allocated resources'

⚠️ 容器 CPU 100% 先换算： 500m 配额下 100% ≠ 整机 100%。nr_throttled 持续增长说明被节流。

八、案例复盘

案例 1：Java 线程死循环打满单核

现象： 订单服务发布后 RT 从 30ms → 800ms，单核 100%

排查： top -H -p 28461 → 线程 28513 占 99% → jstack 显示卡在规则引擎死循环

// 问题代码：死循环 + 正则匹配 3 万条规则
while (true) {
 for (String rule : rules) {
 if (rule.matches(".*VIP.*")) { ... }
 }
}

修复： 摘流 → 回滚 → 缓存预编译规则替代 matches → 加退出条件

效果： 单核 99% → 整机 31%，P99 1.2s → 85ms

案例 2：软中断堆积导致网关 %sys 70%

现象： API 网关高峰 %sys 70%，NET_RX 在 CPU0/1 严重倾斜

排查： cat /proc/softirqs 发现 NET_RX 不均 → ksoftirqd/0 持续占 CPU

修复： 启用 irqbalance + 调整 smp_affinity 使中断均衡分布

效果： %sys 72% → 28%，超时率 5.4% → 0.3%

九、应急响应 — 先止血再排查

CPU 飙到 100% 时，先保护现场再止血，优先恢复业务而非根因分析。

应急流程

1. 固定现场 — top -b -n1 / mpstat / vmstat / dmesg -T | tail -50 留存
2. 判断影响 — 单机还是集群？单进程还是全局？有无关联告警？
3. 止血 — 根据场景选择以下措施
4. 通知 — 同步值班群：影响范围 + 已采取措施 + 预计恢复时间
5. 复盘 — 事后写 RCA（Root Cause Analysis）

止血手段

常见根因速查

十、常驻监控与告警

关键指标

# 整机 CPU > 85% 持续 5 分钟
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85

# 软中断占比 > 25% 持续 3 分钟
avg by(instance) (rate(node_cpu_seconds_total{mode="softirq"}[5m])) * 100 > 25

# 容器节流持续增长
sum by(pod, namespace) (rate(container_cpu_cfs_throttled_periods_total[5m])) > 20

自动快照脚本

当 CPU 告警触发时，自动执行 /usr/local/bin/cpu_hotspot_snapshot.sh 保存现场（详见 raw 源文件）。

关联页面

• linux-essential-commands-reference — Linux 30 个高频命令速查（top/ps/kill 等进程管理命令速查）
• linux-compression-tools-comparison — 压缩解压工具对比（gzip/xz 高 CPU 占用场景）
• java-cpu-100-case-study — Java 应用 CPU 100% 排查实战（四步法 + 四大原因 + 真实案例）