Linux平均负载详解

理解 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 等待、进程排队情况，才能准确定位瓶颈。下次碰到平均负载高，别慌，按上面的步骤一步步排查就行。