LinuxCPU瓶颈分析_top与mpstat实战解析【教程】

7次阅读

CPU 使用率高不等于存在瓶颈,需用 top 和 mpstat 交叉验证:top 显示进程占所有核心总时间的百分比,mpstat 揭示单核中断、软硬中断不均衡等深层问题。

LinuxCPU 瓶颈分析_top 与 mpstat 实战解析【教程】

CPU 使用率高不等于存在瓶颈,topmpstat 看到的数字需要交叉验证才能定位真实问题。

为什么 top 的 %CPU 常被误读

top 默认显示的是每个进程占用的 CPU 时间占「所有 CPU 核心总时间」的百分比。比如 4 核机器上一个进程跑满单核,%CPU 显示为 100%,但整机负载其实只有 25%;若显示 380%,才说明它压满了近 4 个核。

  • 注意看右上角的 load average:它反映的是就绪队列长度,和 CPU 核心数对比才有意义(如 4 核机器 load average 长期 > 4 才值得警惕)
  • %CPU 列排序后,别只盯着数值最大那个——可能是短时抖动,要观察 TIME+(累计 CPU 时间)是否持续增长
  • top 默认不显示线程视图,按 H 键切换后,可能发现某个进程下有几十个高耗时线程,这才是真正的瓶颈源头

mpstat 能补 top 看不见的盲区

top 关注“谁在用”,mpstat 关注“怎么用”——特别是每颗 CPU 核心的软中断、硬中断、iowait 分布。瓶颈常藏在不均衡里。

  • 运行 mpstat -P ALL 1 每秒刷新一次,重点看 %irq%soft:如果某颗核长期高于其他核 5%+,可能是网卡或磁盘中断绑定不均
  • %iowait 高 ≠ 磁盘慢:它只表示 CPU 在等 I/O 完成,而实际 I/O 可能根本没排队(用 iostat -x 1 对照看 await%util
  • 注意 mpstat 的统计粒度是采样周期内平均值,瞬时尖峰会被平滑掉;如需捕获毫秒级抖动,得配合 perf record -e cycles,instructions,irq:softirq_entry

两个命令结果冲突时怎么判断

常见矛盾场景:top 显示 CPU 使用率不到 30%,但 mpstat 显示某核心 %idle 接近 0。这通常意味着该核心被频繁打断,但打断后执行时间极短(比如大量小包网络中断),top 进程视角抓不到。

  • 先运行 cat /proc/interrupts,看哪类中断(如 eth0-TxRx-0)在特定 CPU 上计数飙升
  • sudo perf top -C 0(指定核心 0)观察该核上最热的函数,常看到 __do_softirqtcp_v4_rcv 占比异常高
  • 检查网卡 RSS 配置:ethtool -x eth0 查看接收队列是否只绑定了单核;用 ethtool -X eth0 equal 4 均匀分发可立即缓解
mpstat -P ALL 1 3 Linux 5.15.0-101-generic (srv01) 	04/12/2024 	_x86_64_	(4 CPU)  02:34:11 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle 02:34:12 PM  all   12.25    0.00    3.50    0.00    0.00    0.25    0.00    0.00    0.00   84.00 02:34:12 PM    0   10.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00    0.00   88.00 02:34:12 PM    1   15.00    0.00    5.00    0.00    0.00    0.50    0.00    0.00    0.00   79.50 02:34:12 PM    2    8.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00    0.00   91.00 02:34:12 PM    3   36.00    0.00   16.00    0.00    0.00    1.00    0.00    0.00    0.00   47.00

真正难处理的不是高使用率,而是那种 mpstat 显示单核 %soft 持续 40%+、但 top 里找不到对应进程的情况——这时候你得怀疑是不是内核模块或硬件驱动在后台吃资源。

text=ZqhQzanResources