Linux 负载高但 CPU 空闲的常见原因

负载高但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 等待。