负载高但CPU空闲是因为大量进程处于D状态（不可中断睡眠），它们不占CPU却计入load average；主因是I/O阻塞（如慢盘、NFS hard挂载、驱动异常）或内存直接回收。
为什么 top 显示 CPU 使用率低，但 load average 却很高
负载高但 CPU 空闲，本质是系统中有大量进程处于 uninterruptible sleep（D 状态），它们不消耗 CPU，却会计入负载。Linux 的 load average 统计的是「平均等待运行或等待 I/O 完成的进程数」，不是 CPU 使用率。
常见诱因包括：
- 磁盘 I/O 严重阻塞（如慢盘、RAID 同步、LVM 快照刷新）
- 网络存储挂载异常（NFS/CIFS 连接卡在
hard mount状态） - 内核模块或驱动陷入不可中断等待（如某些加密模块、老旧 RAID 卡固件）
- 内存严重不足触发直接回收（
direct reclaim），导致进程在__alloc_pages_slowpath中 D 等待
如何快速定位 D 状态进程和源头设备
先用 ps 找出 D 状态进程：
ps -eo pid,stat,comm,wchan:30 --sort=-pcpu | head -20
重点关注 STAT 列含 D 的行，以及 WCHAN 列（等待的内核函数名）。常见高危 wchan 包括：io_schedule、nvme_queue_rq、__wait_on_bit、nfs_wait_event。
再查 I/O 压力来源：
-
iostat -x 1：看%util是否持续 100%，await和r_await/w_await是否异常高（>100ms） -
cat /proc/diskstats：对比io_ticks增长速率，确认是否某块盘长期忙 -
lsof +D /mnt/nfs_share（若怀疑 NFS）：看哪些进程卡在该挂载点
NFS hard mount 卡死是高频原因，怎么验证和缓解
NFS hard 挂载下服务端宕机或网络中断时，客户端进程会永久 D 等待，直到服务器恢复——这期间 load 会飙升，top 却看不到 CPU 消耗。
验证方法：
-
find /mnt/nfs -maxdepth 1 -name "*" 2>/dev/null | head -5：如果卡住不动，大概率是 NFS hang -
mount | grep nfs：检查是否用了hard,intr（intr已被废弃，现代内核忽略它） -
rpcinfo -p $nfs_server：确认服务端 NFS daemon 是否响应
临时缓解（不重启）：
- 对已 hang 的挂载点，尝试
umount -f /mnt/nfs（强制卸载，可能失败） - 更可靠的是加
soft+timeo重挂（仅限可容忍数据丢失的场景）：mount -t nfs -o soft,timeo=10,retrans=3 server:/export /mnt/nfs
内核参数和日志里藏着关键线索
dmesg -T 往往有直接证据，比如：
-
INFO: task rsync:12345 blocked for more than 120 seconds.后跟调用栈，常指向 NVMe 超时或 ext4 journal 等待 -
blk_update_request: I/O error, dev nvme0n1, sector 123456789表示硬件/固件层故障 -
nfsv4: server not responding, timed out直接锁定 NFS 问题
关键内核参数影响 D 状态持续时间：
-
/proc/sys/vm/swappiness过高（如 >80）可能加剧 direct reclaim，诱发 D 等待 -
/proc/sys/vm/vfs_cache_pressure异常低（ - 某些云环境需检查
/sys/block/*/device/timeout（如 NVMe 的nvmf超时值是否被设为 0）
真正难排查的，往往是多个小 I/O 请求叠加导致的设备队列饱和，而非单一大文件拷贝。这时候 iostat -x 的 avgqu-sz（平均队列长度）比 %util 更能说明问题——即使 %util 只有 70%，但 avgqu-sz > 32，就代表请求已在排队，后续进程开始 D 等待。
