load average高不等于cpu忙，它统计的是处于可运行（r）和不可中断睡眠（d）状态的进程平均数量；d状态进程等待i/o等资源，不耗cpu却拉高负载，需结合nproc核数判断是否真超标，并用vmstat、iostat、ps等定位根因。

load average 高不等于 CPU 忙，也不代表服务一定卡——它只说明有进程在排队等资源，而这个“资源”可能是 CPU、磁盘 I/O、NFS 响应，甚至某个驱动挂起的不可中断等待。直接杀高 CPU 进程或重启服务，大概率治标不治本。

怎么看 load average 是否真超标

别光看数字大小，先确认分母：nproc 输出的是逻辑 CPU 核数（含超线程），这才是 load 的合理参照系。

• 若 uptime 显示 load average: 12.45, 8.92, 5.30，而 nproc 返回 8，那 1 分钟值 12.45 > 8，确实过载
• 但若 1 分钟值是 3.2，5/15 分钟是 0.5/0.3，说明是短时毛刺，可能只是某个 cron 脚本或日志轮转触发，不用急着干预
• 注意：负载持续 > 0.7 × 逻辑核数 就该关注；> 1 × 逻辑核数 表示已有进程开始排队；> 2 × 逻辑核数 通常已影响响应

为什么 top 里 %CPU 很低但 load 却很高

这是最典型的误导场景，根源几乎都在 D 状态（不可中断睡眠）进程上——它们不消耗 CPU，但会计入 load average。

• 用 ps -eo stat,pid,comm | grep " D " 查看当前 D 状态进程，重点关注状态列含 D 的行
• 常见诱因：NFS 挂载点无响应、本地磁盘故障（如坏道）、RAID 卡降速、云盘 I/O hang、内核模块死锁
• vmstat 1 5 中若 r（就绪队列）不高但 b（阻塞进程）持续 > 0，基本可锁定为 I/O 层阻塞
• 不要用 kill -9 强杀 D 状态进程，它无法被信号中断；得先恢复底层设备或卸载故障挂载点

如何快速定位是哪类资源拖垮了 load

用一组命令组合交叉验证，比单看一个指标可靠得多：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• vmstat 1 5：重点盯 r（就绪进程数）、b（阻塞进程数）、wa（I/O wait 百分比）。若 r 高 + wa 低 → CPU 瓶颈；r 低 + b 高 → I/O 或驱动问题
• iostat -x 1 3：看 %util 是否接近 100%，await 是否长期 > 10ms。SSD 通常 5ms 就需警惕
• pidstat -d 1 3：确认是哪个进程在发大量 I/O，注意 Blk_read/s 和 Blk_wrtn/s 值，不是所有高 I/O 进程都显现在 iotop 里（尤其内核线程）
• dmesg -T | tail -30：查有没有 end_request: I/O error、NMI watchdog、hung_task 等内核级报错，这类日志往往比用户态工具更早暴露根因

容易被忽略的“伪高负载”陷阱

有些高 load 是系统行为导致，并非故障，但会干扰判断：

• 短生命周期进程爆炸：比如每秒 fork 几百个 curl 或 grep 子进程，ps 可能抓不到，但 vmstat 的 cs（上下文切换）会飙升到 10w+/s，r 列也跳变频繁
• 容器环境未限制资源：Kubernetes Pod 没设 resources.limits.cpu，宿主机 load 高，但 top 里看不到对应进程 —— 得进容器命名空间查：nsenter -t <pid> -m -u -i -n -p bash</pid>
• /proc/loadavg 第四项是 running/total 进程数，如 2/341 表示当前 2 个运行中、共 341 个进程。如果 total 接近 65535（PID 最大值），说明进程泄漏，ps -eLf | wc -l 会远超正常值（通常几百到一两千）

真正难处理的，往往是 D 状态进程背后那个不响不动的磁盘或 NFS 服务器——它不报错，只沉默地把整个队列拖住。这时候，strace -p <pid></pid> 通常无效，得靠 lsof -p <pid></pid> 看它卡在哪个文件描述符，再顺藤摸到挂载点或设备节点。