问题背景

CPU 飙高是 Linux 服务器最常见的性能问题之一。典型表现为：监控告警触发（CPU 使用率超过 90%）、业务响应变慢、用户投诉接口超时、ssh 操作卡顿。很多运维同学遇到 CPU 飙高的第一反应是重启服务或直接 kill 进程，这种方法治标不治本，需要系统性地定位根因。

本文按照从全局到局部、从表象到根因的排查思路，分三阶段展开，覆盖从 60 秒快速诊断到代码级热点分析的完整链路。

一、核心知识点速览

排查 CPU 问题前需要理解几个关键概念：

• load average：系统的"平均活跃进程数"，包含正在运行和等待 I/O 的进程。如果 load > CPU 逻辑核数，说明有进程在排队。
• %us / %sy / %wa / %id / %st：CPU 时间的分布——用户态、内核态、I/O 等待、空闲、被虚拟机管理程序偷走。
• **上下文切换 (context switch)**：CPU 在不同进程/线程间切换的频率，过高会浪费 CPU 时间在调度上而非业务上。
• **运行队列 (run queue)**：处于可运行状态但等待 CPU 调度的进程数，超过核数意味着 CPU 饱和。

不区分物理核和逻辑核的场景：排查时关注的是 CPU 的调度单位（逻辑核），nproc 或 lscpu 输出的 CPU(s) 就是逻辑核总数。

二、第一阶段：60 秒全局扫描

登录服务器后，不要急着翻日志，先用一组命令快速了解系统整体状态。这一阶段的目标是定性：到底是 CPU 瓶颈、内存瓶颈、IO 瓶颈，还是网络问题。

2.1 uptime —— 看负载基线

$ uptime 14:32:15 up 12 days,  3:21,  2 users,  load average: 18.52, 15.34, 10.87

如果 load average 超过 CPU 逻辑核数，说明有任务在排队。单看 load 不够，需要结合后面的命令判断瓶颈在哪。

2.2 top —— 看 CPU 时间分布和 TOP 进程

$ toptop - 14:32:15 up 12 days,  3:21,  2 users,  load average: 18.52, 15.34, 10.87Tasks: 256 total,   3 running, 253 sleeping,   0 stopped,   0 zombie%Cpu(s): 12.5 us,  8.3 sy,  0.0 ni, 45.8 id, 33.3 wa,  0.0 hi,  0.0 si,  0.0 stMiB Mem :  31967.6 total,   1224.5 free,  18234.2 used,  12508.9 buff/cacheMiB Swap:   4096.0 total,    345.2 free,   3750.8 used.   7123.4 avail Mem  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND 3456 root      20   0  ......

关键要看的是 %Cpu(s) 这一行的分布：

操作技巧：

• 按 P 键按 CPU 使用率排序
• 按 1 键展开每个逻辑核的负载分布
• 按 c 键显示完整命令行

2.3 vmstat —— 看调度和阻塞

$ vmstat 1 5procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st16  2 204800  12245    ...

只看前四列和 CPU 列：

关键判断：如果 r 高但 wa 低，CPU 是瓶颈；如果 b 高且 wa 高，磁盘是瓶颈；如果 cs 极高，说明线程过多或锁竞争严重。

2.4 mpstat —— 看各核负载是否均衡

$ mpstat -P ALL 1 3Linux 5.15.0-91-generic ... 08/15/2025  _x86_64_ (32 CPU)14:32:15  CPU    %usr   %sys   %iowait    %idle14:32:16  all   12.50   8.30     33.30   45.8014:32:16    0    3.20   5.10     12.40   79.3014:32:16    1   60.50  15.30      5.20   19.00...

关注点：如果个别核 %usr 或 %sys 明显高于其他核，说明存在绑核或单线程瓶颈。如果所有核负载一致偏高，说明是全局限流（如 CPU 密集型任务、连接数打满）。

2.5 第一阶段判断矩阵

三、第二阶段：定位进程与线程

全局扫描定位了方向后，接下来锁定嫌疑进程。

3.1 pidstat —— 按进程统计 CPU

# 每 1 秒统计一次，取 CPU 使用率最高的前 15 个$ pidstat -u 1 5 | sort -k 8 -nr | head -15Linux 5.15.0-91-generic ... 08/15/2025  _x86_64_ (32 CPU)14:35:22      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command14:35:23        0      3456   85.30    2.10    0.00    0.00   87.40     2  java14:35:23      999      5678   12.40    1.20    0.00    0.00   13.60    15  nginx

%wait 列（需要 procps-ng 4.0+）表示进程处于可运行状态但等待 CPU 调度的百分比。如果 %wait 高说明 CPU 确实是瓶颈，进程在排队等待调度。

3.2 top -H —— 看线程级 CPU 消耗

找到嫌疑进程后，看是进程内的哪个线程在吃 CPU：

$ top -H -p 3456

或者一步到位：

$ ps -p 3456 -To pid,tid,%cpu,cmd --sort=-%cpu | head -10  PID   TID %CPU CMD 3456  3456  0.0 java 3456  6789 42.5 java 3456  6790 38.1 java

记下高 CPU 的 TID，转成十六进制用于线程 dump：

$ printf"%x\n" 67891a85

这个十六进制值在线程 Dump（jstack、pstack、/proc/<PID>/task/<TID>/stack）中用于查找对应线程。

3.3 perf top —— 实时代码级热点

perf top 能直接显示哪个函数在消耗 CPU，比 top 精确到代码级别：

# 实时查看 CPU 热点函数（建议先装 linux-tools-common）$ sudo perf top -p 3456 -g

输出示例：

Samples: 1M of event 'cpu-clock', 4000 Hz, Event count (approx.): ...Overhead  Shared Object       Symbol 35.20%  java                [.] JFFS2_write_super 12.50%  libjvm.so           [.] Unsafe_GetLongVolatile  8.30%  [kernel]            [k] _raw_spin_unlock_irqrestore

-g 参数显示调用链，可以逐层回溯是谁调用了这个热点函数。

3.4 perf record：生成火焰图

当需要更精确的分析或对外汇报时，用采样模式：

# 采样 30 秒$ sudo perf record -F 99 -p 3456 -g --sleep 30$ sudo perf report --no-children

参数说明：

• -F 99：每秒采样 99 次，兼顾精度和开销
• -g：记录调用链
• -k 1：强制包含内核栈（重要，否则大量 [unknown]）
• --no-children：展开真实调用深度，避免折叠优化隐藏信息

生成火焰图：

$ sudo perf script -i perf.data > out.perf$ git clone https://github.com/brendangregg/FlameGraph$ cd FlameGraph$ ./stackcollapse-perf.pl ../out.perf > out.folded$ ./flamegraph.pl out.folded > cpu.svg

火焰图横轴是采样比例，纵轴是调用栈。找到最宽的"平顶"区域就是热点函数，从那里往上看调用路径。

3.5 strace -c —— 统计系统调用开销

如果 %sy（内核态 CPU）偏高，用 strace 看系统调用耗时分布：

# 统计 5 秒内系统调用的耗时分布（不带 -p 则启动新进程）$ sudo strace -c -p 3456strace: Process 3456 attached^C% time     seconds  usecs/call     calls    errors syscall------ ----------- ----------- --------- --------- ---------------- 45.20    0.452000          12       376           futex 30.15    0.301500           5       603           epoll_wait 12.10    0.121000           4       302           write  8.50    0.085000           3       283           read

常见高耗时系统调用：

四、第三阶段：根因分类与深挖

根据前两阶段的数据，将 CPU 飙高归入以下典型类别进行针对性排查。

4.1 CPU 密集型任务

特征：%usr 高（> 70%），perf top 显示业务函数占主导。

排查方向：

• 查看是否有新上线的代码逻辑变更
• 检查定时任务（crontab）是否集中在同一时段
• 使用 perf record 生成火焰图确认业务热点

典型场景：突发流量导致连接处理数暴增、某些查询 SQL 通过 ORM 映射成循环查询、正则表达式回溯导致 CPU 打满。

4.2 死循环或无限递归

特征：单进程 CPU 固定 100%（单核），strace -c 显示某个系统调用频率极高。

排查方向：

# 先确认是单线程还是多线程在跑$ top -H -p <PID># 对 Java 应用取 Thread Dump$ kill -3 <PID># 结合前面十六进制的 TID 定位线程

典型场景：某次 while 循环缺少 break 条件、递归调用缺少终止条件、异常重试机制进入死循环。

4.3 锁竞争激烈

特征：%sy 高（> 30%），vmstat 1 的 cs 列 > 50000，strace -e futex 高频。

# 只看 futex 相关调用$ sudo strace -e futex -p <PID># 或用 perf 分析锁相关事件$ sudo perf record -e sched:sched_stat_runtime -p <PID> -- sleep 10$ sudo perf report

典型场景：高并发下 HashMap 扩容死循环（JDK 1.7 及以前）、ArrayList 并发写入、热门行数据库锁、Redis 热点 key。

4.4 上下文切换过高

特征：CPU 消耗不高（%idle 高），但 load average 高，vmstat 的 cs > 80000。

# 查看自愿/非自愿上下文切换$ pidstat -w 1 5

• **自愿切换 (cswch/s)**：线程等待 I/O 或锁时主动让出 CPU，过高可能因为 IO 频繁。
• **非自愿切换 (nvcswch/s)**：时间片用完被强制调度，过高因为线程数过多（超过 CPU 核数太多）。

4.5 中断处理过多

特征：%si（软中断）或 %hi（硬中断）异常高。

# 查看中断分布$ cat /proc/interrupts# 查看软中断$ cat /proc/softirqs

典型场景：网卡 RX 队列中断集中到单个 CPU（RPS/RSS 未配置）、TPS 过高导致网络软中断多。

4.6 云服务器 vCPU 争抢

特征：%st（steal）持续 > 5%，且 %idle 低。

# 持续观察 steal 值$ mpstat -P ALL 1 | grep -v Linux | awk '{print $1,$13}'

%st 表示 hypervisor 从当前 VM 偷走的 CPU 时间。如果持续高于 10%，说明宿主机的 CPU 已超分严重，直接提工单找云厂商。

五、CPU 飙高 8 大根因速查表

六、生产环境注意事项

1. 采样频率控制：perf record 的 -F 不要超过 10000Hz，否则 perf 本身的开销会成为干扰。生产环境推荐 99-997Hz。

2. 必须包含内核栈：perf record -k 1，否则大量热点显示为 [unknown]。

3. 谨慎使用 strace -p：在高并发进程上附加 strace 会导致进程显著变慢（5~10 倍性能下降），建议只在低峰期使用或先统计后采样。

4. 不要直接 kill 高 CPU 进程：除非确认是恶意进程，否则先确认进程归属（java、mysql、httpd 可能有业务在跑）。

5. 绑核排查：如果看到单核 100% 而其他核空闲，检查是否有 taskset 绑核或 irqbalance 未运行。

6. 云服务器注意 %st：如果 %st 高，本地优化无效，直接联系云厂商。

7. 操作前记录现场：

   $ date +%F_%H:%M:%S > /tmp/cpu_debug_$(date +%s).txt$ uptime >> /tmp/cpu_debug_*.txt$ top -bn1 >> /tmp/cpu_debug_*.txt$ vmstat 1 5 >> /tmp/cpu_debug_*.txt

七、总结

CPU 飙高排查的核心思路可以浓缩为三句话：

1. 先 60 秒全局扫描——用 uptime / top / vmstat / mpstat 定性是 CPU、IO、内存还是网络问题。
2. 再锁定嫌疑进程——用 pidstat / perf top / strace 热点分析定位到具体的进程、线程、函数。
3. 最后对症下药——根据根因分类走对应的优化路径：算法优化、锁优化、扩容、配置调整。

盲目重启或加机器只是暂时掩盖问题，只有找到根因才能彻底解决。建议将上述排查流程固化成一个排查脚本，每次 CPU 飙高时自动采集现场数据，再按流程逐步分析。