Linux 负载高但 CPU 空闲，怎样区分 I/O 等待与锁等待

Linux 的 load average 高、CPU 却很空闲，并不矛盾：负载统计的是可运行任务和处于不可中断睡眠的任务，后者常见于磁盘或网络文件系统 I/O。真正要区分 I/O 等待与锁等待，不能只看 top 的一个数字，而要把负载、进程状态、设备延迟和等待点放在同一采样窗口里。

先看 load average 到底在等什么

Linux 的 /proc/loadavg 前三个字段是 1、5、15 分钟平均值，统计对象包括运行队列中的任务和等待磁盘 I/O 的任务；第四个字段则给出当前可运行实体数与系统实体总数。因此，四核机器出现负载 8，不足以证明 CPU 饱和，先要知道队列里究竟是哪一类任务。

先连续采样，而不是只抄一行：

# 用 1 秒间隔观察运行队列、不可中断任务和 CPU 等待比例
uptime
cat /proc/loadavg
vmstat 1 6

vmstat 中的 r 更接近等待 CPU 的可运行任务，b 表示等待 I/O 完成而阻塞的任务，wa 表示 CPU 时间中等待 I/O 的比例。若 r 高且 wa 低，优先看 CPU 调度或锁竞争；若 b、wa 与负载一起升高，I/O 更可疑。这里是分流线索，不是单项指标的定论。

用设备和进程证据确认 I/O 等待

当 wa 或 b 明显升高，继续看设备是否真的出现延迟和队列：

# 观察扩展设备统计，重点看 await、队列和利用率
iostat -xz 1 5

# 按任务查看读写量与块 I/O 延迟，替换为实际服务名或 PID
pidstat -d -p ALL 1 5

iostat -xz 里的 await 是设备 I/O 的平均等待时间，不能脱离设备类型和业务基线解读；pidstat -d 可以把块 I/O 延迟落到任务。再用进程状态和等待点交叉确认：

# 找出不可中断睡眠任务，并显示内核等待点
ps -eo pid,ppid,stat,wchan:32,comm,args --sort=stat | awk '$3 ~ /D/ {print}'

持续出现 STAT=D 且 WCHAN 落在块层、文件系统或网络文件系统路径时，I/O 证据链较完整。若只有瞬时一个 D 状态，不能直接判定磁盘故障；还要结合 iostat 的设备延迟、进程的 iodelay 和业务请求时间。

锁等待要看等待者与拥有者

锁竞争常见的表现是任务没有消耗很多用户态 CPU，但大量线程在同一临界区排队。它可能是应用文件锁、进程间同步，也可能是内核锁；三者的观测入口不同。/proc/locks 展示的是当前文件锁和租约，不能用来证明所有内核锁竞争。

# 查看当前命名空间可见的文件锁，记录拥有者 PID 后再回查进程
cat /proc/locks

# 读取任务的内核等待点；权限不足时只记录可见结果
ps -eo pid,tid,stat,wchan:32,comm --sort=wchan

若要分析内核锁争用，可在允许 perf 的环境中使用 perf lock contention 或内核的 lockstat。perf 可能受 perf_event_paranoid 和权限限制，命令失败不等于没有锁竞争；应记录权限错误，再换用现有 tracing 或应用级指标。判断锁等待的关键是：多个等待者是否集中在同一锁类/调用点，拥有者是否长时间持锁，以及释放后延迟是否同步下降。

把一次采样整理成可复核结论

生产排障时建议保留至少几十秒的同窗数据：负载曲线、vmstat、iostat、任务状态和服务请求延迟要能按时间对齐。只有当“指标升高—等待者出现—等待点一致—处理后回落”形成闭环，才适合把根因写成 I/O 等待或锁等待；否则应标记为待确认，避免误杀进程或盲目调内核参数。

相关问题

CPU 使用率很低，为什么 load average 仍然会上升？

因为等待磁盘 I/O 的任务也会计入负载。先看 vmstat 的 b、wa，再用 iostat 和 pidstat 落到设备与进程。

所有 D 状态进程都代表磁盘坏了吗？

不是。D 代表不可中断睡眠，可能涉及块设备、文件系统或网络文件系统。需要结合 WCHAN、设备延迟和持续时间判断。

/proc/locks 为空是不是没有锁等待？

不是。它主要展示文件锁和租约，应用内互斥锁、运行时锁和内核锁要用应用指标、线程栈或 lockstat/perf 等其他证据。