用 CPUInfo 判断系统负载的正确方式
核心概念与 CPUInfo 的作用
在排查系统性能时，一个常见的误区是混淆了“能力”和“繁忙程度”。/proc/cpuinfo或lscpu这类工具，揭示的是CPU的“家底”：型号、频率、缓存、物理核心与逻辑处理器数量。它们告诉你系统“最多能同时处理多少任务”。
而系统负载（load a verage）呢？它反映的是过去1、5、15分钟内，处于可运行或不可中断状态的平均进程数，直白地说，就是“有多少任务在排队等着或正在被处理”。
所以，判断负载是否“过高”，关键在于找一个参照物。你不能孤立地看一个负载数字，而必须把它和系统的处理能力——也就是逻辑CPU的数量——放在一起比较。CPUInfo正是用来获取这个关键“对照基准”的。这里还有一个重要提醒：高负载并不总是CPU算力不足的锅，频繁的I/O等待同样会让进程排起长队，这一点后面会详细展开。
从 CPUInfo 获取对照基准
那么，如何从CPUInfo中提取我们需要的基准信息呢？下面这几个命令是基本功：
- 查看逻辑CPU数（这是负载对比的黄金阈值）：
grep -c ^processor /proc/cpuinfo - 查看物理CPU个数：
grep “physical id” /proc/cpuinfo | sort -u | wc -l - 查看每颗物理CPU的核心数：
grep “cpu cores” /proc/cpuinfo | uniq
如果想省事，lscpu命令会以更直观的方式，把CPU架构、核心与线程数、NUMA信息等一次性展示给你。
它们之间的关系很明确：总逻辑CPU数 = 物理CPU个数 × 每颗核心数 × 超线程数（如果支持）。举个例子，如果你的系统逻辑CPU数是8，那么通常来说，1、5、15分钟的负载平均值长期超过8，就意味着CPU资源已经相当紧张了（当然，偶尔的瞬时峰值可以接受）。
结合负载数据做判断
拿到了基准，接下来就是读取负载数据。常用的命令有uptime、w、cat /proc/loada vg或者top命令的首行。你需要关注的就是那三个数字：1分钟、5分钟、15分钟的平均负载。
判断逻辑可以快速归纳为：
- 负载值 ≈ 逻辑CPU数：CPU资源基本被吃满，系统处于高负荷运行状态。
- 负载值 > 逻辑CPU数：任务已经开始排队，系统存在瓶颈，需要进一步诊断。
- 趋势比绝对值更重要：如果1分钟负载 > 5分钟负载 > 15分钟负载，说明负载正在上升；反之，则意味着负载在逐步缓解。
再次强调，单看“CPU使用率”这个百分比，很多时候解释不了高负载现象。如果大量进程卡在I/O等待上，CPU使用率可能不高，但负载却会飙升。这正是下一部分要解决的问题。
定位高负载的配套命令
当负载警报响起，你需要一套组合拳来定位真正的瓶颈。以下命令各司其职：
- 整体资源与队列概览：
vmstat 1。重点关注r（运行队列长度）、b（阻塞进程数）、si/so（内存换入换出，反映swap使用）、wa（I/O等待时间百分比）。 - 进程级资源占用：
top或htop。按P键按CPU使用率排序，观察us（用户态）、sy（内核态）、wa（I/O等待）的分布。 - 每颗CPU核心的使用率：
mpstat -P ALL 1（来自sysstat包）。这个命令能帮你识别是否出现了单核性能瓶颈，而其他核心却在“围观”。 - 历史负载数据回溯：
sar -q或查看/var/log/sa/sa??文件（需要安装并启用sysstat服务）。这对于分析间歇性性能问题至关重要。 - 磁盘I/O瓶颈排查：
iostat -x 1。关键指标是%util（设备利用率）和await（平均I/O等待时间），如果这两个值持续很高，磁盘很可能就是罪魁祸首。 - CPU频率与电源管理：
watch -n 1 “cat /proc/cpuinfo | grep ‘cpu MHz’”，以及检查/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor文件（查看是powersa ve还是performance模式）。CPU降频运行也会导致性能下降。
快速排障流程
把上面的知识点串联起来，就形成了一套高效的排障流程：
- 定基准：先用CPUInfo相关命令，确定系统的逻辑CPU数量。
- 看负载：读取1、5、15分钟负载，判断是否超过逻辑CPU数，并观察其变化趋势。
- 深挖根因（如果负载高）：
- 运行
top，如果wa值很高，立即用iostat检查磁盘状态。 - 运行
vmstat 1，观察r和b队列，以及是否有内存交换（si/so）。 - 运行
mpstat -P ALL 1，检查是否存在单颗CPU核心被“打满”的情况。 - 必要时，使用
sar -q回溯历史负载数据，寻找规律。
- 运行
- 拓宽视野（如果负载不高但系统响应慢）：这时瓶颈很可能不在CPU。应优先排查I/O、内存（如频繁swap）、网络延迟等其他因素。
- 优化方向：根据定位到的瓶颈采取行动。可能是优化数据库慢查询、调整应用线程池、减少锁竞争、引入缓存或异步处理，也可能是升级磁盘/网络硬件，或者在虚拟化环境中直接扩容vCPU。
