系统负载不是CPU使用率，而是1/5/15分钟内处于就绪（R）或不可中断睡眠（D）状态的进程平均数量；需除以CPU核心数（用grep -c processor /proc/cpuinfo获取）判断是否过载，如15分钟值持续超0.7倍核心数即表明稳定承压。
系统负载不是 CPU 使用率，三个数字分别代表 1/5/15 分钟内处于 R（就绪）或 D（不可中断睡眠）状态的进程平均数量；光看数值没用，必须除以 CPU 核心数才能判断是否真过载。
uptime 输出的 load average: 0.45, 0.32, 0.28 到底怎么看
这是最常用也最容易误读的入口。三个数不是百分比，也不是 CPU 占用率，而是单位时间内的“排队+卡住”进程数均值：
-
0.45：过去 1 分钟的指数加权平均，对瞬时抖动敏感，适合发现突发任务 -
0.32：过去 5 分钟的平均，衰减适中，是诊断真实压力的首选参考值 -
0.28：过去 15 分钟的平均，反映长期趋势，若它持续高于0.7 × CPU核心数，说明系统已稳定承压
注意：cat /proc/cpuinfo | grep -c 'processor' 才是准确获取逻辑 CPU 数量的方式；lscpu 中的 CPU(s) 也可能含超线程，但负载评估应以实际可调度单元为准（即 processor 行数）。
为什么 top 里 load 高但 %Cpu(s) 显示 95% idle
这是典型 I/O 瓶颈信号——大量进程卡在 D 状态（如磁盘响应慢、NFS 挂起、驱动阻塞），它们不消耗 CPU 时间，但会计入负载。
- 验证方法：
ps -eo stat,pid,comm | grep " D "查看当前 D 状态进程 - 对比
cat /proc/loadavg第四字段（如2/124），斜杠前的2是当前就绪+不可中断进程总数 - 配合
iostat -x 1观察%util是否接近 100%，await是否异常升高（> 10ms 值得警惕）
此时杀掉高 CPU 进程无济于事，真正要查的是存储链路、文件系统挂载选项或硬件响应延迟。
/proc/loadavg 文件里第五个数字（如 19876）是什么
它不是负载，而是当前系统中最近一次创建的进程 PID。这个值本身对负载分析无直接意义，但可辅助判断：
- 若该值增长极快（比如几秒内跳变上千），可能有 fork 炸弹或短生命周期进程风暴
- 结合第四字段（如
2/124）看：斜杠后124是当前总进程数，若它远大于你预期的常驻服务数，需用ps aux --sort=-ppid | head -20排查异常父进程 - 该字段不会被
uptime或top显示，仅用于脚本采集时做额外上下文补充
别把它和负载值混为一谈——前三个才是核心指标，第五个只是顺带记录的副产品。
vmstat 的 r 列和 load average 的关系
vmstat 2 5 输出中的 r 列（run queue length）是当前就绪态进程数的实时快照，而 load average 是它的指数加权平滑结果。两者本质同源，但用途不同：
-
r值瞬间跳到 8 并回落，可能是临时编译任务；但 load average 的5 分钟值持续 > 6，说明这种压力已成常态 - 如果
r长期 ≥ CPU 核心数，且b列（blocked）也非零，基本可断定是 I/O 阻塞叠加 CPU 争用 -
vmstat每次采样间隔默认 1 秒，比uptime的 5 秒粒度更细，适合做短期波动归因
真正难处理的不是单次高负载，而是 r 和 load average 同步抬升且无法回落——这时要检查是否有内存回收（kswapd）、OOM killer 日志或 cgroup 资源限制被触发。
