Linux系统性能监控：从平均负载到每CPU核心使用率详解

1. 从“平均负载”到“单核使用率”：一个常见的认知误区

很多刚接触Linux系统监控的朋友，第一反应可能就是去看 top 或者 uptime 命令输出的平均负载（Load Average）。屏幕上那三个数字，比如 0.05, 0.10, 0.15，常常被误解为CPU使用率的百分比。这其实是一个经典的误区。平均负载反映的是系统在特定时间间隔内，处于可运行状态（正在使用CPU或等待CPU）和不可中断状态（通常是在等待I/O，如磁盘读写）的平均进程数。它是一个宏观的系统压力指标，并不能告诉你每个CPU核心此时此刻的繁忙程度。

举个例子，一个4核的服务器，平均负载长期在3.8左右，这通常意味着CPU资源被充分利用。但如果平均负载是8.0，而你的CPU只有4个核心，这就明确指示系统已经过载，有进程在排队等待CPU时间片了。然而，你无法从这个“8.0”中分辨出，是其中一个核心被单个计算密集型进程（比如视频编码）100%占满，而其他核心闲置；还是四个核心都被均匀地占用到了80%。这两种情况对系统性能的影响、以及后续的优化方向，是截然不同的。

因此，当我们需要进行精细化的性能调优、定位单线程应用的性能瓶颈、或者排查因CPU核心间负载不均导致的“热点”问题时，查看每个独立CPU核心的使用率就变得至关重要。这能帮助我们回答诸如“我的应用是否没能有效利用多核？”、“是不是某个核心的软中断（softirq）处理压力过大？”、“虚拟机的vCPU绑定是否合理？”等具体问题。今天，我们就来深入聊聊，在Linux命令行下，有哪些趁手的工具和方法，可以让我们像“打开任务管理器性能标签页”一样，清晰地洞察每一个CPU核心的实时状态与历史负载。

2. 核心工具详解：从实时监控到历史回溯

Linux生态提供了从简单到复杂、从实时到历史的丰富工具集，来满足我们查看每个CPU使用率的需求。我们可以根据场景，灵活选用。

2.1 实时监控的利器：mpstat 与 top

对于需要实时观察CPU核心瞬时状态的情况，mpstat 和 top 是最直接的选择。

mpstat - 专为多核统计而生

mpstat（Multiprocessor Statistics）是 sysstat 工具包的一部分，它天生就是为汇报每个CPU核心的统计数据设计的。如果你的系统没有安装，可以通过包管理器轻松获取（例如，在基于Debian/Ubuntu的系统上使用 sudo apt install sysstat，在基于RHEL/CentOS的系统上使用 sudo yum install sysstat）。

它的基本用法非常直观：

这个命令会每秒刷新一次（1 是间隔秒数），汇报所有CPU核心（-P ALL）的详细使用情况。输出类似下面这样：

我们来解读一下关键列：

• CPU: 核心编号。all 表示所有核心的聚合平均值，0, 1, 2, 3 则对应四个独立的核心。
• %usr: 在用户态（应用程序）运行的时间百分比。
• %sys: 在内核态运行的时间百分比。%usr + %sys 大致等于我们常说的“CPU使用率”，但更精确。
• %iowait: CPU等待I/O（如磁盘、网络）完成的时间百分比。这是一个非常重要的指标，如果某个核心的 %iowait 持续很高，可能意味着它服务的进程正在遭遇存储或网络瓶颈。
• %soft: 处理软中断的时间百分比。网络包处理、定时任务等常常会引发软中断。如果某个核心（特别是CPU 0）的 %soft 异常高，可能是网络流量过大或出现了“软中断风暴”。
• %idle: CPU空闲时间的百分比。这是最直观的“空闲率”。

通过 mpstat，你可以一眼看出哪个核心最忙，忙在什么地方（是用户计算、系统调用，还是在等I/O）。这对于初步判断负载是否均衡极为有用。

top 命令的进阶视图

大家熟悉的 top 命令，在默认界面按数字 1，就可以切换到显示每个CPU核心使用率的视图。顶部汇总信息会从一行变成每个核心一行，显示类似 Cpu0, Cpu1... 的实时使用率分解（us, sy, ni, id, wa, hi, si, st）。这个视图是交互式的，适合在已经打开 top 做进程监控时，快速切换视角查看核心负载分布。

注意：top 的每核数据显示是瞬时值，刷新频率受 top 的刷新间隔影响。而 mpstat 可以通过参数设置固定的、带时间戳的采样间隔，并且输出格式更规整，更适合记录和后续分析。两者可以配合使用，top 用于交互式浏览，mpstat 用于脚本化采集或长时间监控。

2.2 深入内核细节：/proc/stat 文件

所有上层工具的数据源头，几乎都来自于Linux内核暴露的 /proc 文件系统。/proc/stat 文件记录了自系统启动以来，CPU时间的累计值，精确到每一个核心。

查看这个文件：

你会看到以 cpu 开头的多行，第一行 cpu 是总和，后续 cpu0, cpu1... 对应每个核心。每一行的数字代表从系统启动开始，该CPU在各种状态下花费的“滴答”数（通常一个滴答是10毫秒）。这些状态包括：

• user: 用户态时间。
• nice: 低优先级（nice值>0）用户态时间。
• system: 内核态时间。
• idle: 空闲时间。
• iowait: 等待I/O时间。
• irq: 处理硬中断时间。
• softirq: 处理软中断时间。
• steal（虚拟化环境）: 被宿主机“偷走”的时间。
• guest（虚拟化环境）: 运行虚拟CPU的时间。

如何手动计算瞬时使用率？

工具的计算逻辑其实很简单：在时间点T1采样一次 /proc/stat，等待一个间隔（比如1秒）后，在时间点T2再次采样。然后，针对你关心的核心（比如cpu0），计算：

1. 总时间差 = (T2所有状态之和) - (T1所有状态之和)
2. 非空闲时间差 = (T2的user+nice+system+...) - (T1的user+nice+system+...)
3. 瞬时使用率 = (非空闲时间差 / 总时间差) * 100%

例如，你可以写一个简单的Shell脚本来实现这个逻辑，针对每个核心进行计算。这虽然不如现成工具方便，但能让你彻底理解CPU使用率指标的底层原理，在无法安装额外工具的环境（如最小化容器）中尤其有用。

2.3 历史数据分析与图形化：sar 与可视化工具

当问题发生在过去，或者我们需要分析一段时间的趋势时，实时监控工具就无能为力了。这时，就要请出 sar（System Activity Reporter，同样来自 sysstat 包）这位“历史学家”。

sysstat 包默认会安装一个定时任务（通常通过 cron），每10分钟收集一次系统性能数据（包括每CPU数据），并保存到 /var/log/sysstat/ 或类似目录下。你可以使用 sar 命令来回溯这些数据。

查看当天所有CPU核心的历史数据：

查看指定日期的数据（例如查看3月10日的数据）：

sar 的输出格式和 mpstat 类似，但带有了具体的时间点。你可以用它来回答：“今天下午两点左右，CPU使用率飙升，是哪个核心先开始的？主要耗时在哪个状态？”

对于更复杂的分析和呈现，尤其是在需要向他人报告时，图形化工具能提供更直观的视角。sysstat 包中的 sadf 命令可以将 sar 的数据导出为其他格式（如CSV、JSON），进而导入到 Grafana、Excel 等工具中生成图表。社区也有像 collectl、Netdata、Prometheus + Node Exporter（配合 Grafana 仪表盘）等更现代化的监控方案，它们不仅能监控每CPU使用率，还能与进程、内存、网络等指标关联分析，构建完整的性能监控体系。

3. 核心使用率不均的典型场景与排查思路

看到每个核心的使用率后，我们常会发现它们并不均衡。这不一定总是问题，但如果是以下情况，就需要深入排查了。

3.1 场景一：单核CPU使用率100%，其他核心闲置

这是最典型的单线程应用瓶颈。当你运行一个没有做并行化设计的计算密集型程序（比如某些老版本的压缩工具、部分科学计算脚本）时，它只能在一个CPU核心上运行，导致该核心被占满，而系统整体的“平均使用率”看起来却不高。

排查与确认：

1. 使用 top 命令，按 1 查看各核使用率，确认是否只有一个核心（比如Cpu2）的 %us 或 %sy 接近100%。
2. 在 top 的进程列表中，查看哪个进程的 %CPU 很高（可能超过100%，因为 top 的 %CPU 是占所有核心总和的百分比）。记下其PID。
3. 使用 ps -eo pid,comm,psr,pcpu 命令，其中 psr 字段明确显示了该进程当前被绑定在哪个CPU核心上运行。你可以过滤查看高CPU进程：ps -eo pid,comm,psr,pcpu --sort=-pcpu | head -20。
4. 更进一步，可以使用 perf 工具对高CPU进程进行采样分析（sudo perf top -p <PID>），查看其热点函数，从代码层面确认是否缺乏并行化。

解决方案：对于可修改的应用，考虑使用多线程（如pthreads）或多进程（如fork）进行并行化改造。对于不可修改的单个任务，如果有很多同类独立任务（比如处理大量图片），可以用脚本启动多个进程，并通过 taskset 命令将它们绑定到不同的核心上，实现粗粒度的并行。

3.2 场景二：某个核心的 %soft 或 %si 异常偏高

这通常指向网络或定时器相关的软中断处理压力集中。在Linux中，网络数据包的处理、定时器回调等任务，会以软中断的形式触发。默认情况下，许多软中断会由CPU 0来处理，这很容易导致CPU 0成为瓶颈，即使网络流量本身并不大。

排查与确认：

1. 使用 mpstat -P ALL 1，观察是否主要是CPU 0（有时也包括CPU 1）的 %soft 列数值显著高于其他核心。
2. 使用 cat /proc/softirqs 可以查看各种类型软中断的累计计数。配合 watch -d cat /proc/softirqs 可以观察其变化速率，找出增长最快的软中断类型，常见的有 NET_RX（网络接收）、NET_TX（网络发送）、TIMER（定时器）等。
3. 如果 NET_RX 增长迅猛，结合 sar -n DEV 1 查看网络接口流量，确认是否匹配。

解决方案：启用RPS/RFS或调整软中断亲和性。现代网卡驱动和内核支持多队列（RSS），可以将不同的网络流哈希到不同的硬件队列，从而分散中断。对于单队列网卡或需要进一步优化的情况，可以配置：

• RPS (Receive Packet Steering): 在软件层面，将单个接收队列的网络包分发给多个CPU核心处理。
• RFS (Receive Flow Steering): 在RPS基础上，确保同一个网络连接的数据包被送到同一个CPU核心，提高缓存命中率。 配置这些功能需要修改 /sys/class/net/<网卡名>/queues/rx-<队列号>/rps_cpus 等内核参数。这是一项高级优化，需要根据具体硬件和内核版本进行调整。

3.3 场景三：虚拟化环境中的 %steal 过高

在云服务器或虚拟机中，mpstat 和 top 会多出一个 %steal 或 st 指标。它表示虚拟CPU等待宿主机分配物理CPU时间的时间百分比。如果你的虚拟机CPU使用率不高，但 %steal 却很高，说明宿主机物理资源竞争激烈，你的虚拟机无法获得足够的CPU时间片。

排查与影响： 这通常不是虚拟机内部能解决的问题，而是宿主机超售或邻居虚拟机过于活跃导致的。高 %steal 会直接导致虚拟机内应用响应变慢、性能抖动。监控这个指标对于云上应用性能评估和问题定位非常关键。如果持续出现高 %steal，可能需要考虑升级虚拟机规格（获得更多vCPU或独占资源），或者与云服务提供商沟通。

4. 实战：编写一个简易的每CPU监控脚本

理解了原理和工具后，我们可以动手写一个简单的Shell脚本，模拟 mpstat 的核心功能，加深理解。这个脚本特别适合在那些极度精简、没有安装 sysstat 的环境中使用。

脚本使用说明：

1. 将上述内容保存为 per_cpu_monitor.sh。
2. 赋予执行权限：chmod +x per_cpu_monitor.sh。
3. 运行：./per_cpu_monitor.sh 或指定间隔 ./per_cpu_monitor.sh 5（5秒刷新一次）。
4. 按 Ctrl+C 停止。

这个脚本实现了最核心的差值计算逻辑，并输出了几个关键指标。它非常直观地展示了 /proc/stat 数据是如何被转化成我们熟悉的百分比形式的。你可以根据需要，轻松地修改它来增加或减少显示的指标列。

5. 高级话题与性能调优关联

监控的最终目的是为了优化。理解了每CPU使用率，可以将其与更广泛的性能调优工作流结合。

与进程/线程绑核（CPU Affinity）协同：taskset 和 numactl 命令可以将进程或线程绑定到指定的CPU核心上。这在以下场景有用：

• 缓存友好：将关键进程绑定到固定核心，提高CPU缓存命中率。
• 隔离干扰：将某个高优先级应用绑定到一组核心，将其他后台任务绑定到另一组，避免竞争。
• NUMA架构优化：在NUMA服务器上，让进程使用与其所在内存节点直连的CPU，避免远程内存访问带来的延迟。通过 numactl --hardware 查看NUMA拓扑，结合每CPU使用率观察，可以做出更优的绑定决策。

作为容器编排的参考：在Kubernetes等容器编排平台中，你可以为容器设置CPU请求（requests）和限制（limits）。了解应用的真实每核使用模式，有助于设置更合理的资源请求。例如，一个单线程应用，即使它需要很高的计算能力，其CPU请求也应设置为 1 核，而不是 4 核，因为额外的核它无法利用。同时，监控容器内进程的实际CPU亲和性，可以验证编排器的调度是否符合预期。

性能剖析（Profiling）的入口：当你发现某个核心使用率异常时，它就是进行深度性能剖析的明确入口。使用 perf record -C <cpu_id> -g 可以针对特定核心进行采样，生成火焰图，精准定位在该核心上消耗CPU最多的函数调用栈。这比全局采样更能聚焦问题根源。

从宏观的平均负载，到微观的每个CPU核心使用率，再到深度的软中断、绑核与性能剖析，这条监控链路为我们提供了从发现现象、定位瓶颈到实施优化的完整视野。掌握这些工具和方法，意味着你不仅能回答“系统卡不卡”，更能精准地回答“为什么卡，卡在哪里，以及如何让它不卡”。这正是在复杂的生产环境中进行有效性能管理和故障排查的核心能力之一。