/proc/loadavg第4字段分子为当前R状态进程数，反映CPU可运行队列长度；第5字段隐含D状态进程信息，需结合ps查D进程及/proc/[pid]/io、iostat等定位I/O瓶颈，load高不等于CPU忙。
直接看 /proc/loadavg 的前三个数字（1/5/15分钟平均负载）只能知道“有多少进程在排队”，但无法区分是 CPU 争抢还是 I/O 等待。真正能拆解原因的，是它的第4和第5个字段——它们提供了实时、细粒度的运行队列快照。
看第4字段：当前运行队列长度（runnable tasks）
执行 cat /proc/loadavg，输出形如：
其中 3/331 的分子 3 就是当前时刻处于 R 状态（可运行） 的进程数 —— 这些进程要么正在 CPU 上跑，要么就绪等待调度。
如果这个值持续 ≥ CPU 核心数（用 nproc 查），说明 CPU 调度层已饱和，大概率是 CPU 密集型任务过多；若该值很小（比如 1~2），但整体 load 却很高（如 15+），那问题几乎一定出在不可中断等待上。
看第5字段：不可中断进程数（uninterruptible tasks）
同一行中 3/331 的分母 331 是当前总进程数，但它不直接反映 D 状态进程。真正关键的是：不可中断进程（D 状态）数量 = 总进程数 − 可运行进程数 − 其他状态进程数，而最快速的验证方式是：
- 运行
ps aux | awk '$8 ~ /D/ {print}'，列出所有 D 状态进程 - 结合
cat /proc/loadavg中的分子（R 数）与实际观察到的 D 进程数对比：若 D 进程数多且稳定（如 >5 个），同时 load 高、CPU 使用率低、vmstat中 wa 值高，则确认是 I/O 等待拖累负载
联动验证：用 /proc/[pid]/io 判断是否真在等磁盘
找到 D 状态进程 PID 后，查看其 I/O 行为：
-
cat /proc/[PID]/io关注 rchar/wchar（字符级读写量）和 read_bytes/write_bytes（实际物理 IO 量） - 若 read_bytes/write_bytes 很小，但 syscw/syscw 很大（系统调用次数高），说明进程频繁发起小 IO 请求却卡在内核等待完成，典型如日志同步、数据库 fsync 或 NFS 挂载点卡顿
- 再配合
iostat -x 1看 %util ≈ 100% 且 await 显著升高（>20ms），基本锁定磁盘响应慢或设备过载
注意一个常见误判点：load 高 ≠ CPU 忙
Linux 的 load average 包含 R（可运行）和 D（不可中断）两类进程，而 top 或 mpstat 显示的 CPU 使用率只统计了真正占用 CPU 时间的 us/sy/id。所以会出现：
- load = 16，CPU 使用率仅 30%，wa = 65% → 大量进程卡在磁盘 I/O，不是 CPU 不够
- load = 16，CPU 使用率 98%，wa
