Load Average 是“运行中+不可中断等待”进程数的平均值，非 CPU 使用率；需结合逻辑 CPU 数判断是否超标，并通过 %wa、%sy、%us 及 D 状态进程定位瓶颈。
Load Average 不是 CPU 使用率
很多人一看到 load average: 2.45, 1.98, 1.72 就立刻查 top 看 %us/%sy，以为数值高=CPU烧干了——这是最常见误解。真实情况是：它统计的是「正在运行（R）」+「等待不可中断资源（D）」的进程（更准确说是线程）数量平均值，和 CPU 时间占用无直接换算关系。
-
R状态进程在争抢 CPU，会拉高 CPU 使用率； -
D状态进程卡在磁盘 I/O、NFS、内核锁等不可中断操作上，CPU 几乎不干活，但照样计入 load； - 所以
load=10+%us=15%完全可能，此时瓶颈大概率是存储或驱动，不是 CPU。
怎么判断 load 是否真的超标？必须结合逻辑 CPU 数
单看数字毫无意义。关键基准是系统能并行调度多少线程：nproc 或 grep -c 'processor' /proc/cpuinfo 输出的值。比如输出 8，说明有 8 个可调度线程（如 4 核 8 线程），那么：
load ：一般安全，还有余量；-
load ≈ 8：已接近满负荷，需关注趋势； -
load > 12且持续 5 分钟以上：大概率存在排队，但得继续排查是 R 还是 D 导致的。
注意：不要用物理核心数（lscpu | grep 'Core(s)' ）代替逻辑线程数，超线程（HT）也参与调度。
快速定位是 CPU 争抢还是 I/O 卡死
执行 top -b -n1 | head -20，重点看两行：
-
%wa（iowait）> 20% 且 load 同步升高 → 大量进程堵在D状态，查磁盘：用iostat -x 1 3看%util和await； -
%sy异常高（>40%）+cs（context switch）在vmstat 1中持续 > 10000/s → 可能是短命进程风暴（如 fork 炸弹）、中断异常或内核模块问题； -
%us高 +load ≈ nproc→ 真· CPU 密集型过载，再用pidstat -u 1找热点进程。
别忽略 D 状态进程——它们不占 CPU 却推高 load
D 状态进程无法用 kill 终止，常被误认为“僵尸”，其实它是真·阻塞态。一个长期卡在 D 的进程（比如挂载异常的 NFS 目录下的 ls）会让 load 持续虚高，却查不到 CPU 消耗者。
- 列出所有 D 进程：
ps aux | awk '$8 ~ /D/ {print $2, $11}'； - 查它的堆栈（需 root）：
cat /proc/，看卡在哪个内核函数（如/stack nfs_wait_bit_killable）； - 常见诱因：坏盘、NFS 服务宕机、内核 bug、某些硬件驱动 hang 住。
真正难缠的负载问题，往往藏在 D 状态里——它不消耗资源，却让整个系统响应变慢，还掩盖了真正的瓶颈点。
