最稳、最轻量的方式是读 /proc/loadavg：awk '{print $1,$2,$3}' /proc/loadavg 输出三值，对应1/5/15分钟平均负载，它表示就绪态（R）和不可中断睡眠态（D）进程数的指数移动平均值，非CPU使用率。
直接看 uptime 或 top 第一行的 load average 三个数，就是系统平均负载——它不是 CPU 使用率，而是就绪态（R）和不可中断睡眠态（D）进程数的指数移动平均值。
怎么快速拿到 load average 数值（适合脚本或终端一眼扫）
最稳、最轻量的方式是读 /proc/loadavg：
-
awk '{print $1,$2,$3}' /proc/loadavg→ 输出类似0.45 0.32 0.28，对应 1/5/15 分钟均值 - 不要用
top -n1 | grep "load average"：输出格式受终端宽度、locale 影响，极易解析失败 -
uptime最简洁，但输出含时间等冗余字段；w功能等价，多带登录用户信息
load average 三个数到底怎么看（别被 1 分钟值带偏）
它们分别是过去 1 分钟、5 分钟、15 分钟的平均负载，但意义不同：
-
1 分钟值波动大，适合看突发（比如刚跑完一个大任务），不适合判断常态 -
5 分钟值是日常监控主力，反映中短期压力趋势 -
15 分钟值最平滑，运维常用它做基线比对；若它持续高于逻辑核数，说明系统已稳定承压 - 三者呈“递减”（如
1.2, 0.9, 0.7）是健康信号；若“倒挂”（如0.5, 1.1, 1.8），说明负载在快速累积
负载高但 CPU% 很低？这是最典型的误判点
因为 load average 包含等待 I/O 的 D 状态进程，而 %Cpu(s) 只统计 CPU 时间分配：
- 现象：
load average: 8.2, 7.6, 7.1（8 核机器），但%Cpu(s): 12.5%us, 85.2%id - 结论：瓶颈不在 CPU，而在磁盘/NFS/网络等 I/O 层
- 下一步必须查：
iostat -x 1（看%util和await）、iotop（定位具体进程）、vmstat 1（看r列是否持续 > 核数） - 注意：
%wa高 ≠ 一定磁盘慢，也可能是某个进程反复 open() 不存在的文件，或 NFS 挂载点卡住
怎么结合 CPU 核数判断是否真过载
load average 没有归一化，必须除以逻辑核心数才具可比性：
- 先确认核心数：
nproc（最准）或grep -c '^processor' /proc/cpuinfo - 单核机器：长期 >1.0 就算排队；双核机器：>2.0 才算满；32 核机器：>5.0 完全正常
- 阈值建议按 0.7 × 核数设预警（如 8 核设 5.6），而非死守 “1.0” —— 那只适用于单核
- 别信“负载 = CPU 使用率%”这种换算：Linux 内核没这回事，
/proc/loadavg第四字段斜杠前的数字（如5/124中的5）才是当前就绪+D态进程瞬时数，更接近“此刻排队多少人”
真正难的是区分“CPU 算不过来”和“卡在 I/O 上等响应”，这两个场景的负载表现几乎一样，但排查路径完全不同。盯着 load average 本身看不出区别，必须立刻切到 %Cpu(s) 行和 iostat 才能撕开表象。
