uptime末尾三个数即1/5/15分钟平均负载，非cpu使用率，而是r+d状态进程均值；应读/proc/loadavg防解析错误，结合逻辑核数判断每核负载，并排查d进程与i/o瓶颈。
直接看 uptime 末尾三个数，就是平均负载
不用犹豫，uptime 是最轻量、最可靠的入口。它输出末尾形如 load average: 0.42, 0.38, 0.35 的三组数字，分别对应过去 1 分钟、5 分钟、15 分钟的平均负载值。
注意：这不是 CPU 使用率，而是单位时间内处于可运行（R）或不可中断睡眠（D）状态的进程平均数量。数值为 1.2，意思是平均有 1.2 个任务在排队等 CPU 或 I/O 资源。
常见错误现象：
- 把
top第一行的%Cpu(s)和load average混在一起读——它们维度不同，不能互相印证 - 看到
load average: 4.5就认为 CPU 忙爆了，结果%Cpu(s) id显示空闲率 80%，实际是磁盘卡住了一批 D 状态进程
脚本里别解析 uptime 输出，改读 /proc/loadavg
/proc/loadavg 是内核原始数据源，格式永远固定：0.42 0.38 0.35 2/124 19876，前三个字段就是你要的 1/5/15 分钟负载。
为什么不用 uptime | awk '{print $10}'？因为字段会漂移：中文 locale 下“up”变“已运行”，busybox 版本可能省略用户数，$10 一跑就错。
实操建议：
- 取 5 分钟负载做告警阈值：
awk '{print $2}' /proc/loadavg - 想同时知道当前就绪+D状态进程数？看第四个字段斜杠前面的数字：
awk '{print $4}' /proc/loadavg | cut -d'/' -f1 - 该文件权限是
-r--r--r--，普通用户可读，无需sudo
负载高但 CPU 空闲？重点查 D 状态进程和 I/O
当 load average 明显高于逻辑 CPU 数（用 grep -c 'processor' /proc/cpuinfo 查），而 top 中 %Cpu(s) id 还很高，说明瓶颈不在 CPU 计算，而在 I/O 或驱动层。
关键动作：
- 找 D 状态进程：
ps -eo stat,pid,comm | grep ' D '（前后加空格避免匹配到DEAD或DEBUG） - 看磁盘响应：
iostat -x 1，关注await（>100ms 有风险）和%util（持续接近 100% 表示饱和） - 验证是否真卡在 I/O：
vmstat 1 5，盯b列（blocked 进程数）是否长期 > 0
别只盯着一个数字，要结合核心数算“每核负载”
负载值本身没意义。假设你有 4 核，load average: 3.8, 3.9, 3.7 是忙但尚可；如果是 5.2, 5.6, 6.1，就得动手排查了。
更稳妥的做法是算“15 分钟每核负载”：awk '{print $3}' /proc/loadavg | xargs -I{} echo "scale=2; {}/$(grep -c 'processor' /proc/cpuinfo)" | bc
容易被忽略的点：
- 虚拟机里看到的 load average 可能虚高——宿主机资源争抢也会透传到客户机的
/proc/loadavg -
htop默认显示的 load average 条形图是映射成百分比的，不是原始值，别拿它做数值判断 - 容器环境（如 Docker）中，
uptime读的是宿主机值，而top在容器内可能受 cgroup 限制，两者数值不一致属正常
