深入理解 Linux 平均负载，是进行系统性能调优的基础技能。许多运维人员在看到 uptime 命令输出的三个数值时常常感到困惑——这三个数字究竟代表什么含义？什么范围属于正常？何时需要触发告警？接下来将核心原理逐一拆解，帮助快速掌握平均负载的分析方法。
在理想状态下，平均负载应等于 CPU 核心数量。如何快速查询 CPU 个数？执行以下命令即可得到结果：
grep 'model name' /proc/cpuinfo | wc -l
仅凭单一数值往往难以判断负载真实状况。综合观察 1 分钟、5 分钟、15 分钟这三个时间点的负载值，能够更立体地把握系统运行趋势。举例来说：在单 CPU 服务器上测得平均负载为 1.73、0.60、7.98，这意味着最近 1 分钟内系统超载 73%，而过去 15 分钟内的超载幅度高达 698%——但数据呈现下降趋势，说明状态正在恢复。
那么，何时需要人为干预？经验判断标准是：当平均负载持续超过 CPU 数量的 70% 时，就应当启动深入排查。负载过高会导致进程响应延迟，最终影响业务服务的正常运转。
这里需要先厘清一个常被混淆的概念：平均负载与 CPU 使用率并不等同。平均负载统计的是单位时间内处于可运行状态以及不可中断睡眠状态的进程总数——它不仅涵盖正在占用 CPU 的进程，还包括等待 CPU 调度以及等待 I/O 完成的进程。而 CPU 使用率仅反映 CPU 的忙碌程度。两者在某些场景下表现一致，在某些场景下则可能出现偏离：
- CPU 密集型进程：大量消耗 CPU 资源，平均负载与 CPU 使用率同步上升，两者趋势相同。
- I/O 密集型进程：进程在等待 I/O 操作时也会被计入平均负载，但此时 CPU 可能处于空闲态，因此平均负载偏高但 CPU 使用率未必高。
- 大量进程争抢 CPU：进程排队等待调度，平均负载与 CPU 使用率均可能处于较高水平。
正因这种差异，在排查平均负载升高的问题时，必须根据实际情况采用不同工具来定位根源。下面通过几个常用工具演示如何精准分析。
分析工具
核心工具有三个：iostat、mpstat、pidstat。它们能够帮助我们区分究竟是 CPU 瓶颈、I/O 瓶颈，还是进程数量过多导致的排队现象。
1. CPU 密集型进程
先通过 uptime 发现平均负载偏高，接着运行 mpstat 监控所有 CPU 核心的状态：
$ uptime
# -P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒后输出一组数据
$ mpstat -P ALL 5
# 间隔 5 秒后输出一组数据
$ pidstat -u 5 1如果观察到 CPU 使用率（%usr）持续居高不下，基本可以断定是 CPU 密集型进程导致了平均负载飙升。此时 pidstat 能够清晰展示具体是哪个进程在大量消耗 CPU。
2. I/O 密集型进程
同样先查看平均负载，然后使用 mpstat 重点关注 CPU 的 %iowait 指标：
# 显示所有 CPU 的指标，并在间隔 5 秒输出一组数据
$ mpstat -P ALL 5 1
# 间隔 5 秒后输出一组数据，-u 表示 CPU 指标
$ pidstat -u 5 1若 %iowait 明显升高，而 CPU 使用率并不高，则说明平均负载升高的主要原因是 I/O 等待。这类问题需要进一步结合 iostat 分析磁盘的读写状况。
3. 大量进程的场景
当系统中运行的进程数量超过 CPU 的处理能力时，进程便会进入等待队列。先执行 uptime 查看负载，再用 pidstat 观察每个进程的等待时间：
$ uptime
# 间隔 5 秒后输出一组数据，-u 表示 CPU 指标
$ pidstat -u 5 1重点关注输出中的 %wait 列——该数值代表进程等待 CPU 的时间占比。如果大量进程的 %wait 都很高，说明 CPU 已过载，进程正在排队争抢有限的计算资源。这种情况下，要么增加 CPU 核心数量，要么优化进程数量或调整调度策略。
更多
若希望快速找出处于高 I/O 状态的进程（即 R 状态或 D 状态），可使用以下命令统计各进程的并发线程数：
# 查看高IO进程
$ ps -e -L h o state,cmd | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr该命令会将处于可运行（R）和不可中断睡眠（D）状态的线程提取出来，并按出现次数降序排列。如果某个进程的 D 状态线程数特别多，大概率是 I/O 争用导致的性能瓶颈。
总的来说，平均负载是一个综合性指标，不能孤立解读。只有结合 CPU 使用率、I/O 等待时间、进程排队状况等多维度数据，才能准确锁定系统瓶颈。下次遇到平均负载偏高时，不必慌张，按上述步骤逐步排查即可。
