linux系统负载平均值是过去1/5/15分钟处于可运行或不可中断状态的进程平均数，非cpu使用率；需结合cpu核心数判断高低，推荐直接读取/proc/loadavg获取稳定数值。
直接看 uptime 末尾三个数，但别只读数字
这三个数（比如 0.42, 0.38, 0.35）就是 1/5/15 分钟负载平均值，但它们本身不说明“高不高”——必须结合 CPU 核心数判断。比如你有 4 个逻辑核，load average: 5.2, 5.6, 6.1 才算持续超载；如果是 1.2, 1.0, 0.9，其实很健康。
常见错误：把 uptime 输出里 load average 后面的数字当成 CPU 使用率。它不是 %，也不是进程总数，而是“平均有多少任务在排队等 CPU 或 I/O”。
脚本里别用 uptime | awk '{print $10}' 提取负载
字段位置会漂移：中文 locale 下 “up” 变成 “已运行”，用户数变化、busybox 版本差异都会导致 $10 拿错值。真正稳的方式是直读内核源文件：
-
awk '{print $2}' /proc/loadavg—— 稳定拿到 5 分钟值，适合告警阈值 -
cat /proc/loadavg输出固定五列：0.42 0.38 0.35 1/1234 12345，前三个就是负载，第四个斜杠前的数字（如1）是当前就绪+不可中断进程数，比 uptime 更实时 -
/proc/loadavg权限是-r--r--r--，普通用户可读，不用sudo
负载高但 %Cpu(s) id 很高？重点查 D 状态进程
这是最常被忽略的典型误判场景：负载 4.5，CPU idle 却还有 80%，说明大量进程卡在不可中断睡眠（D 状态），通常卡在磁盘 I/O、NFS 或驱动上。
立刻执行：
-
ps -eo stat,pid,comm | grep " D "—— 查当前 D 状态进程 -
vmstat 1 5看b（blocked 进程数）和wa（I/O wait %） -
iostat -x 1看%util是否长期 ≈ 100%
如果 /proc/loadavg 第四字段斜杠前数字（如 23/124 中的 23）远大于 ps r | wc -l 的结果，基本锁定 I/O 层问题。
top 和 htop 显示的 load average 为啥有时和 uptime 不一致
本质来源相同，都是读 /proc/loadavg，但显示时机不同：uptime 是快照，top 默认每 3 秒刷新一次，htop 可能启用了 CPU 百分比映射模式（F2 → Display Options → Show CPU average），把负载值强行画成条形图，造成数值错觉。
更隐蔽的问题出现在容器环境：宿主机上的 uptime 读的是全局负载，而容器内 top 可能因 cgroup 限制读到被截断的值。真要对比，统一用 cat /proc/loadavg 最可靠。
最容易被跳过的其实是时间维度：只盯 1 分钟值，会错过缓慢爬升的趋势。15 分钟值 > 1.0 且持续上升，比单次 1 分钟突刺更值得干预。
