Linux 服务器出现 load average 过高但 CPU 使用率低的情况通常是磁盘 I/O 瓶颈或进程处于不可中断睡眠状态D 状态导致的。建议优先检查 iowait 占比和阻塞进程而不是盲目增加 CPU 资源。先说结论高负载低 CPU 使用率绝大多数是 I/O 等待或内核态阻塞引起的重点排查磁盘读写、Swap 交换和网络文件系统挂载。先确认通过 top 或 vmstat 确认 waiowait值是否偏高先处理定位占用 I/O 的进程并检查磁盘健康状态谨慎操作挂载点再验证观察负载数值是否随 I/O 等待降低而回落工具准备与安装部分排查命令需要安装特定包建议提前准备# CentOS/RHEL yum install -y sysstat iotop procps # Ubuntu/Debian apt install -y sysstat iotop procps安装完成后即可使用 pidstat、iostat 等命令。分步排查与实操1. 确认 I/O 等待情况运行 top 命令观察 CPU 行中的 wa 值。如果 wa 值持续较高例如超过 30%且显著高于 idle 值说明瓶颈在 I/O。top - 10:00:01 up 10 days, 1:00, 1 user, load average: 8.50, 8.20, 8.10 Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.5 us, 0.2 sy, 0.0 ni, 98.0 id, 1.3 wa, 0.0 hi, 0.0 si, 0.0 st解读上图中 load average 高达 8.50但 CPU idle 仍有 98.0%wa 为 1.3%。若 wa 升高至 30% 以上且 idle 大幅下降则确认为 I/O 瓶颈。2. 查找阻塞进程使用 pidstat 或 iotop 找出读写磁盘最频繁的进程。注意有些内核线程或驱动问题也可能导致进程卡在 D 状态此时 iotop 可能看不到明显占用需结合 ps 查看状态为 D 的进程。# 查看进程级 I/O 统计每秒刷新 pidstat -d 1 # 实时查看 I/O 占用进程需 root iotop -o # 查看处于不可中断睡眠状态D 状态的进程 ps -eo stat,pid,comm | grep ^D解读pidstat 输出中关注 kB_rd/s 和 kB_wr/s 列ps 命令若输出大量 D 状态进程通常意味着底层存储响应极慢或硬件故障。3. 检查磁盘硬件与日志运行 dmesg 查看是否有磁盘报错。如果是云服务器检查控制台是否有磁盘性能受限或底层存储异常的通知。dmesg -T | grep -i error # 示例输出 [Mon Oct 10 10:00:00 2023] end_request: I/O error, dev sda, sector 12345 [Mon Oct 10 10:00:01 2023] Buffer I/O error on dev sda1, logical block 67890若出现类似 I/O error 或 Buffer I/O error表明磁盘可能存在物理坏道或连接故障。4. 检查挂载点与网络存储如果使用了 NFS 或其他网络文件系统网络延迟或服务端故障会导致客户端进程不可中断。# 先检查是否有进程占用挂载点 lsof f -- /mnt/nfs_share # 若无关键进程占用再尝试卸载测试 umount /mnt/nfs_share注意生产环境严禁直接 umount必须先通过 lsof 确认无关键业务进程占用否则可能导致服务异常或数据丢失。怎么验证是否生效处理完成后持续运行 uptime 或 top 观察 load average 数值。正常的表现是随着 I/O 等待wa降低负载数值逐渐回落至 CPU 核心数附近。同时检查业务日志确认没有因 I/O 超时产生的新报错。风险与常见坑谨慎处理 D 状态进程处于 D 状态的进程通常无法被 kill 掉。若必须重启服务器请在确保数据已同步或业务允许中断的前提下操作强制重启可能导致数据丢失。忽略 Swap 交换内存不足导致频繁 Swap 交换也会产生大量 I/O 等待检查 free -m 确认内存状态必要时调整 swappiness 参数。监控盲区部分虚拟化环境下宿主机 I/O 争抢会导致客户机显示高 iowait此时需联系服务商排查底层存储性能。盲目卸载挂载点即使是非关键挂载点也可能有后台日志进程正在写入操作前务必使用 lsof 确认。来源 https://www.zjcp.cc/ask/10842.html