load average三个数统计的是过去1分钟、5分钟、15分钟内平均处于runnable（r）或uninterruptible（d）状态的进程数，采用指数加权移动平均算法计算，反映系统整体任务压力而非cpu使用率。
load average三个数到底在统计什么
它们不是CPU使用率，也不是百分比，而是过去1分钟、5分钟、15分钟内，平均有多少进程处于Runnable（R状态，等待CPU或正在用CPU）或Uninterruptible（D状态，比如卡在磁盘I/O、NFS挂载、内核锁里）的状态。内核每5秒采样一次，用指数加权移动平均算法算出这三个值。
关键点：/proc/loadavg第四个字段（如2/415）的分子才是“此刻就绪+不可中断进程数”，是瞬时快照；而load average是平滑后的均值——所以它跳得慢，但掩盖了短时尖峰。
怎么判断这三个数算不算高
必须先知道逻辑核数：nproc最可靠，grep -c 'model name' /proc/cpuinfo也行。拿load值除以核数，得到“平均每个核要处理几个任务”：
load / nproc ：系统有余量，健康-
load / nproc > 1.0：开始排队，需关注 -
load / nproc > 1.5：明显过载，响应延迟大概率已出现
别信“负载>1就报警”——8核机器load=6.0（即6.0 / 8 = 0.75）完全正常；1核小VPS上load=1.2就已经吃紧了。
1分钟、5分钟、15分钟数值趋势怎么看
看三者大小关系比看单个绝对值更有价值：
-
1m > 5m > 15m（如4.2, 2.8, 1.5）：负载正在快速上升，可能是突发流量、死循环或定时任务堆积，要立刻查top -o %CPU和ps aux --sort=-pcpu | head -10 1m （如<code>0.9, 2.1, 3.7）：负载在缓慢恶化，问题可能长期存在，比如内存泄漏导致频繁swap、日志轮转卡住、cron脚本没清理临时文件-
1m ≈ 5m ≈ 15m（如5.6, 5.7, 5.5）：稳态高负载，硬件可能不足，或架构设计没压测到位
特别注意：%wa高（top第三行）但%id不低，说明CPU空闲，但大量进程卡在D状态——这时候vmstat 1 3看b列（不可中断进程数），再用iostat -x 1定位具体设备或lsof +D /mnt/nfs查NFS卡点。
自动化监控里怎么安全取值
top和uptime输出格式受终端宽度、locale影响，绝不能用top -n1 | grep "load average"解析：
- 取稳定负载值：直接读
/proc/loadavg，例如awk '{print $1,$2,$3}' /proc/loadavg - 取当前就绪+不可中断进程数（瞬时值）：
vmstat 1 1 | tail -1 | awk '{print $1,$2}'，第一列r是就绪数，第二列b是D状态数 - 写告警脚本时，用
awk '$1 > 5.6 {print "ALERT"}' /proc/loadavg比用top更稳——但记住，这个5.6必须根据nproc动态算，不能写死
真正容易被忽略的是：load average本身不区分R和D状态。一个load=10的系统，可能是10个CPU密集型进程在抢核，也可能是9个进程卡在NFS hang、1个在跑计算——前者调优方向是限频或扩容，后者得先解决I/O阻塞。不结合ps、vmstat、iostat交叉验证，光看那三个数，等于只看了半张诊断单。
