Linux 负载高但 CPU 不忙怎么查：从 D 状态、iowait 到磁盘队列的排查顺序

凌晨的订单导出开始变慢，接口 CPU 图却只在 20% 左右。值班同学看到 uptime 的 1 分钟负载从 1.8 拉到 18，第一反应是“机器算力不够”。随后几次采样却发现，真正积压的不是计算，而是一批进程卡在 D 状态，磁盘等待把负载抬了起来。Linux 的负载高并不等于 CPU 一定忙，先分清可运行任务和不可中断 I/O 等待，排查会快很多。

负载高不等于 CPU 满负载，统计规则里同时包含正在排队抢 CPU 的任务，以及卡在不可中断 I/O 等待的任务，后者哪怕不占 CPU 时间也会把负载数值拉高。

先确认：高负载不一定是 CPU 瓶颈

先取两份相隔几秒的样本，不要只截一张监控图就下结论：

uptime
cat /proc/loadavg
vmstat 1 5

uptime 会给出最近 1、5、15 分钟的负载。/proc/loadavg 除了这三个数字，还能看到当前可运行任务数和系统任务总数。关键区别在于：负载不只看正在使用或等待 CPU 的任务，也会统计处在不可中断等待中的任务；后者常和磁盘、网络文件系统或块设备访问有关。

因此，8 核机器上看到负载 16 并不能直接推出“CPU 已经跑满两倍”。若同一时段 us、sy 都不高，wa 却连续上涨，或者 b 长时间大于 0，就该把检查方向从算力转到等待链路。

把现场按时间线留住，别让下一轮波动覆盖证据

这次导出故障里，第一分钟只看到了负载上升；第三分钟才看到 b 增加；第五分钟用进程状态定位到同一批导出任务。把每一轮采样留在同一份值班记录里，后面的判断才有前后关系。

表里的时间和数字只是演示记录方式，不是可套用的阈值。不同内核、磁盘类型、挂载方式和业务批量都会改变波动形态；真正有价值的是让负载、等待比例、进程状态和业务动作落在同一时间轴上。

第二轮采样：用 r、b、wa 把猜测缩小

vmstat 1 5 的价值不在于背每一列，而在于看这三类信号是否同向变化：

• r 偏高且 CPU 的用户态或内核态长期饱和，才更像是计算任务排队。
• b 持续出现，表示有任务进入不可中断睡眠，值得继续看 I/O 和进程状态。
• wa 连续升高时，CPU 时间正花在等待 I/O 完成；它不是设备故障的证明，却是继续查看设备、挂载和队列的强信号。

这里容易踩一个坑：把某一秒的 wa=0 当成排除依据。批量任务常以突发方式提交读写，单次采样可能刚好落在空档。更稳妥的是在业务高峰的完整窗口采 30 到 60 秒，并把采样结果和导出队列长度、请求耗时对齐。

看到 D 状态后，先把等待落到具体进程

ps 的 STAT 列能帮助筛出进程状态。D 通常表示不可中断睡眠，常见于 I/O 等待，但它不是“磁盘已经坏了”的结论。先把 PID、父进程、命令名和等待位置放在一起看：

ps -eo state,pid,ppid,comm,wchan:32 --sort=state | awk '$1 ~ /^D/ {print}'
cat /proc//wchan
cat /proc//stack

wchan 只是辅助线索。它能告诉你任务正阻塞在什么内核等待点附近，却不能单独替代设备、文件系统或远端存储的证据。若多个进程同时围绕同一挂载目录、同一块盘或同一个文件服务等待，再结合设备延迟、队列长度和应用日志，就能从“机器很慢”收敛到具体依赖。

别把所有 D 状态都归咎于本地磁盘

同样是 D，来源可能完全不同：本地块设备拥塞、网络文件系统响应慢、容器卷的后端存储延迟、日志目录被高并发写入，甚至某个驱动或文件系统路径异常。先找共同的文件路径、设备名、挂载点和调用来源，再根据实际依赖决定下一步。

现场处置时我更愿意先减小新增压力，而不是直接终止所有等待中的任务。比如把导出投放改成有限并发、暂停非关键的批量归档、把日志写入从同步主链路里拆开。这样做不能修好存储，却能避免等待队列继续增长，同时保留足够的证据给后续定位。

修复动作要和证据对应，别只加机器

给存储扩容有时是正确动作，但应该放在证据之后。若真正问题是凌晨多个任务同时扫同一目录，单纯把机器换大只会让更多任务更快冲到同一个瓶颈。先把排队入口收住，再修复慢路径，最后回放一次接近真实的批量窗口，才能确认处理是否有效。

把这条排查链路变成可复用的告警

防复发不必一开始就堆很多指标。针对这类场景，至少把 1 分钟负载、CPU iowait、不可中断进程数量、关键挂载延迟和导出队列长度放进同一告警面板。告警触发后先自动保存 uptime、vmstat 和 D 状态进程清单，值班人员拿到的是时间一致的证据，不是事后才想起去跑的命令。

第二个改动是给批量任务设置明确边界：每次投放多少、并发上限是多少、超过多长时间要暂停、失败后从哪里续跑。负载数字只是表象，真正能削弱事故影响的是把工作量和等待时间都限制在可控范围内。

相关问题

load average 超过 CPU 核数就一定要扩容吗？

不一定。先区分负载里的任务是在抢 CPU，还是在等待 I/O。CPU 未满而 D 状态和 iowait 上升时，扩容计算资源通常不是第一选择。

ps 里有 D 状态进程可以直接杀掉吗？

不要把终止进程当成定位手段。不可中断等待中的进程未必能立即退出，贸然处理还可能破坏业务现场。先记录 PID、等待点、挂载路径和设备状态，再按业务窗口处置。

iowait 很低，是不是就能排除存储问题？

不能完全排除。采样窗口太短、压力集中在少数任务或等待来自远端依赖时，都可能让单个 CPU 指标不显眼。结合 D 状态、设备延迟和业务路径判断更稳。

容器里的负载高和宿主机负载高该看哪一个？

先明确告警来自哪个命名空间和监控口径，再同时核对容器的工作负载、卷挂载和宿主机的 I/O 情况。只看其中一边容易漏掉共享存储或节点级竞争。

核对资料

• Linux 内核文档：/proc/loadavg 的字段说明
• uptime(1)：负载包含可运行和不可中断状态任务
• ps(1)：进程状态码说明