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，说明大块连续内存无法分配，可能触发内核阻塞