Linux的load average是就绪队列长度均值，非CPU使用率；三个数值分别代表1/5/15分钟平均就绪或不可中断进程数，需结合CPU核数、%wa、r/b列等多维度判断真实负载。
没有“具体的系统负载百分比”这种东西——Linux 的 load average 是就绪队列长度均值，不是 CPU 使用率，也不能直接换算成百分比。 你真正需要的，是结合进程状态、CPU 核数、I/O 等多个维度交叉判断的负载真相，而不是一个假想的“80% 负载”数字。
怎么读 load average 这三个数？
执行 uptime、w 或打开 top 首行，你会看到类似 load average: 1.25, 0.98, 0.72 的输出：
- 第一个数（1.25）：过去 1 分钟内，平均有多少进程处于 就绪或不可中断睡眠（D 状态） —— 即等待 CPU 或等待 I/O 完成
- 第二个（0.98）和第三个（0.72）：分别是 5 分钟和 15 分钟均值，更反映趋势；重点关注它，而非跳动的 1 分钟值
- 这三个数本身无单位，也 不除以 CPU 核数再乘 100 就得到“负载率” —— 那是常见误用
判断是否异常，必须先知道逻辑核数：nproc（最稳）或 grep -c 'model name' /proc/cpuinfo。2 核机器上持续 >2.0 才算压满；32 核机器上 5.0 完全正常。
top 里真正反映 CPU 占用的是哪一行？
top 第一行的 load average 和第三行的 %Cpu(s) 完全不同源，别混淆：
-
%Cpu(s): 12.3%us, 2.1%sy, 0.0%ni, 84.5%id, 1.1%wa这行才告诉你 CPU 时间分配 -
%wa高（比如 >20%）≠ 磁盘坏了，可能是某个进程反复open()不存在的文件，或 NFS 挂载点卡住 -
%id低但load average高？说明大量进程卡在 D 状态（如磁盘 I/O、锁竞争、NFS hang），CPU 其实没忙，只是调度队列堆满了
自动化脚本里怎么安全取负载值？
top 是交互式程序，输出格式随终端宽度、locale 变化，绝不能用 top -n1 | grep "load average" 解析：
- 取稳定负载值：直接读
/proc/loadavg，例如awk '{print $1,$2,$3}' /proc/loadavg - 取当前就绪进程数（r 列）和不可中断进程数（b 列）：用
vmstat 1 1 | tail -1 | awk '{print $1,$2}' - 设预警阈值：比如 8 核机器，想在负载持续超 5.6（8 × 0.7）时告警，写成
awk '$1 > 5.6 {print "ALERT"}' /proc/loadavg
注意：/proc/loadavg 的第四字段形如 2/124，斜杠前是当前就绪 + 不可中断进程数（瞬时快照），后是总进程数；这个比 load average 更接近“此刻排队多少人”，但仍是瞬时值，不适合单独做判断。
为什么 htop 或 mpstat 有时比 top 更有用？
当 load average 高但 %Cpu(s) 看似空闲时，问题往往不在 CPU 本身：
-
htop按F4搜索关键词（如java、nginx），再按u过滤用户，能快速定位某服务下所有进程是否集体卡在 D 状态 -
mpstat -P ALL 1 1显示每个逻辑 CPU 的利用率，如果只有 1 个核跑满 100%，其余全 idle，大概率是单线程瓶颈，不是整体负载高 -
vmstat 1关注r（就绪队列长度）和b（不可中断进程数）：若r长期 > 逻辑核数，说明调度已排队；若b持续 >0，得查 I/O 或内核锁
真正容易被忽略的，是把 load average 当作“CPU 使用率”来调优——它背后混着 CPU 调度、磁盘延迟、锁竞争、甚至网络挂起，只盯一个数字，永远找不到根因。
