load 高但 CPU 空闲？D 状态线程排查记

凌晨告警：三台机器 load 25 但 CPU 利用率只有 12%，业务没挂但响应变慢。这种 load 高 CPU 闲的场景，大概率是 IO 等待或锁。

先确认 load 构成：

vmstat 1 5          # b 列是阻塞线程数，50+ 说明大量任务在等
ps -eLo stat,comm | grep ^D | sort | uniq -c | sort -rn | head

D 状态（不可中断睡眠）进程是 load 的主要贡献者，逐个看内核栈：

cat /proc/<pid>/stack    # 看卡在哪个内核调用

三台机器的 D 进程全落在 NFS 挂载的读操作上。存储侧确认：NFS 服务端磁盘故障重建中，读延迟从 2 毫秒飙到 8 秒。应用读了 NFS 上的配置文件，每次读都卡住一个工作线程，线程池被拖光，连带 CPU 任务排队，于是 load 高而 CPU 闲。

处置：把 NFS 挂载点切到本地缓存副本应急，load 五分钟内回落。根治是把这批配置读取改成本地文件加启动时同步，运行时不再碰 NFS。

复盘补了一个监控盲区：过去只看 CPU 利用率，没看 load 与 CPU 的偏离度。新告警规则：load 五分钟均值超核数两倍且 CPU 利用率低于 30% 时报疑似 IO 问题，附 D 进程数。

另一个常见成因是 Java 的某些 VM 操作或文件系统日志提交，判断方法一样：找到 D 状态看内核栈。load average 的本质是运行队列加不可中断任务数，理解了这个定义，它就从玄学变成了精确的线索。

顺带一提 D 状态的兄弟场景： NFS 重挂载僵死时，kill 都无效，只能等 IO 超时或重启。这类问题的预案是关键路径避免同步依赖远程存储，我们后来把配置读取全部本地化，单点故障的传染性被彻底切断。

这次排查后 D 状态进入了团队的标准排查手册，配套还有一行快捷命令：统计 D 状态线程并按内核栈聚合，输出直接指向卡住的子系统。工具化之后，这类问题新人也能十分钟上手，老同学的经验变成了所有人的起点，这才是排障知识管理的正确姿势。