Linux平均负载高而CPU利用率低的根本原因是：load average统计的是正在运行或不可中断等待（D状态）的进程数，CPU利用率仅反映CPU执行指令的时间占比；高负载低利用率通常表明大量进程卡在I/O等待，而非密集计算。
这种情况很常见，根本原因在于：Linux 的 load average 统计的是“正在运行或不可中断等待”的进程数，而 CPU 利用率 只反映 CPU 实际执行指令的时间占比。两者维度不同——高负载低利用率，通常意味着大量进程卡在 I/O 等待（D 状态），而不是在拼命计算。
看 iowait 是否异常升高
打开 top，重点观察 CPU 行里的 wa 值：
- wa 持续超过 5%，尤其伴随 idle 高、us/sy 很低，基本可锁定 I/O 瓶颈
- wa 接近 0 但 load 仍高，说明问题不在磁盘读写，要转向 D 状态进程或内存换页
- 注意 wa 是“CPU 等待 I/O 完成的时间比例”，不是 I/O 本身快慢的直接指标，需结合其他工具交叉验证
查有没有大量 D 状态进程
D 状态（不可中断睡眠）进程会抬高负载却几乎不耗 CPU，常因磁盘响应慢、NFS 挂载失效、驱动卡死引起：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 执行
ps -eo pid,stat,comm,wchan --sort=-wchan | head -15，关注 STAT 含 D 的行和 wchan 列（如io_schedule、nfssvc、ext4_writepages） - 简单统计：
ps -eo stat | grep "^D" | wc -l，结果大于 5 就值得警惕 - 若发现多个进程卡在同一个内核函数（比如都停在
__nvme_submit_cmd），大概率是 NVMe 设备响应异常
检查磁盘与存储后端健康状况
I/O 瓶颈未必来自本地硬盘，云盘、NFS、iSCSI、Ceph 等都可能成为源头：
- 运行
iostat -x 1，重点关注：%util是否长期 100%、await是否 > 100ms、avgqu-sz是否持续偏高 - 查内核日志：
dmesg -T | grep -i "error\|timeout\|buffer\|nvme\|ata"，留意I/O error on dev sda或link down类报错 - 云环境特别注意“无声降级”：例如 AWS EBS gp2 卷突发 IOPS 耗尽后限速，
iostat不报错但await陡升、load 暴涨
排除内存不足引发的连锁反应
内存严重不足时，系统频繁 swap 和刷脏页，会把内存压力转为 I/O 压力，间接推高 load：
- 用
vmstat 1观察si（swap in）和bi（block in）是否持续非零 - 执行
free -h，看Available是否远低于总内存，且SwapFree接近 0 - 检查
/proc/buddyinfo，若高阶内存（如 order-9/10）为 0，说明大块连续内存无法分配，可能触发内核阻塞
