Linux 负载很高但 CPU 很闲：load average、iowait 与 D 状态进程排查

现象

监控告警说服务器负载很高，uptime 显示 load average 十几，但 top 里 CPU 使用率不高，甚至大部分时间是空闲的。这是典型的“负载不等于 CPU 使用率”的情况。本文说明原因，并给出一套排查顺序。

一、load average 到底统计什么

在 Linux 上，load average 是单位时间内处于“可运行”（R 状态，正在或等待使用 CPU）和“不可中断睡眠”（D 状态，通常在等待磁盘或某些内核资源）的任务数的平均值。展示的三个数字分别是过去 1、5、15 分钟的平均。

因此：

• 负载高且 CPU 使用率高：CPU 不够用，任务在排队。
• 负载高但 CPU 空闲：大量进程卡在 D 状态，多半是 IO 或锁等待。

判断是否“高”要和 CPU 核数比较，nproc 查看核数。负载持续明显高于核数才值得关注，具体阈值要结合业务延迟表现。

二、先看整体：谁在等

uptime
vmstat 1 5

vmstat 里重点看几列：

• r：可运行队列长度，持续大于核数说明 CPU 争用。
• b：处于不可中断睡眠的进程数，持续大于 0 说明有 IO 等待。
• wa：CPU 花在等待 IO 的时间比例。
• si/so：换入换出，非零说明发生了内存交换。

三、找出 D 状态进程

ps -eo state,pid,ppid,wchan:32,cmd | awk '$1=="D"'

wchan 列显示进程阻塞在内核的哪个函数上，可以辅助判断是磁盘、NFS 还是其他资源。也可以直接用 top 按状态观察。

四、确认磁盘是否是瓶颈

iostat -x 1 5

关注：

• %util：设备繁忙程度，持续接近 100% 说明饱和（对于并行能力强的设备，这个数字参考价值有限）。
• await：平均每次 IO 的等待时间，明显升高说明延迟变大。
• aqu-sz（旧版本是 avgqu-sz）：队列长度。

再用 pidstat 找出是哪个进程在产生 IO：

pidstat -d 1 5

没有 iotop、pidstat 时，安装 sysstat 和 iotop 包。

五、常见原因与处理

1. 磁盘 IO 打满：日志刷盘、备份、批量导入、慢查询产生大量临时文件。限制并发、错峰、调整刷盘策略，必要时升级磁盘规格。云上的云硬盘有性能上限（IOPS 和吞吐），到限后表现为延迟升高，需要对照监控确认。
2. 内存不足引发交换：free -h 查看，vmstat 的 si/so 非零。处理内存泄漏或扩容，不要靠加大 swap 掩盖。
3. 网络文件系统卡住：NFS 服务端无响应时，访问挂载点的进程会进入 D 状态，一直不退出。检查挂载和网络，必要时用软挂载或设置超时参数（需评估数据一致性风险）。
4. 大量线程等待锁或数据库：这类等待通常是 S 状态，不计入负载；如果负载里有大量 R，则要回到 CPU 争用的方向。
5. 短时间内创建大量进程或线程：vmstat 的 cs（上下文切换）异常高，可以用 pidstat -w 查看。

六、一个排查流程

1. uptime 与 nproc 比较，确认是否真的过载。
2. vmstat 1 判断是 r 高（CPU）还是 b 高（IO）。
3. CPU 方向：top、pidstat -u 找高占用进程，必要时用 perf top 进一步分析。
4. IO 方向：iostat -x 看设备，pidstat -d 找进程，ps 看 D 状态进程的 wchan。
5. 处理后观察 1 分钟、5 分钟负载是否回落，并补上监控告警。

小结

• Linux 的 load 包含 D 状态进程，CPU 空闲时负载依然可能很高。
• vmstat 的 r、b、wa 三列能快速区分 CPU 与 IO 问题。
• 用 iostat、pidstat 和 ps 的 wchan 定位到具体设备和进程，再对症处理。