Linux系统负载不是CPU使用率，而是单位时间内处于可运行状态（R）或不可中断睡眠状态（D）的平均进程数。它反映的是“排队等资源”的任务有多少，而不是“正在干活”的强度。判断是否异常，必须结合CPU核心数来看——比如8核机器，15分钟负载长期超过12（即1.5倍核心数），就该介入了。
看懂load average三个数字
执行uptime或top，看到类似load average: 12.45, 8.92, 5.30，含义是：
- 第一个数（12.45）：过去1分钟的平均负载，波动大，适合看突发情况
- 第二个数（8.92）：过去5分钟的平均负载，更稳定，常作为当前压力参考
- 第三个数（5.30）：过去15分钟的平均负载，反映长期趋势，最能说明问题是否持续
若三个值呈下降趋势（如15 → 10 → 5），说明高峰已过；若持续攀升（如3 → 6 → 9），则问题在恶化。别只盯着第一个数做判断。
先比核心数，再定是否真过载
负载数值本身没意义，必须和CPU总核心数对比：
- 查核心数：nproc 或 grep -c 'model name' /proc/cpuinfo
- 安全阈值：负载 ÷ 核心数
- 举例：4核机器，load5 = 6.2，意味着平均有2个以上进程在等待，已超负荷
三指标联动，快速定位瓶颈类型
仅看load average无法知道“谁在捣鬼”，要同步观察三个关键指标：
- CPU使用率（top第三行%Cpu(s)）：us高→应用计算密集；sy高→内核开销大（如频繁小文件读写）
- I/O等待时间（wa%）：wa持续＞5%，大概率是磁盘拖慢，进程卡在D状态
- 运行队列长度（vmstat 1中的r列）：r值长期大于核心数，说明调度队列积压
典型组合：
- load高 + us低 + wa高 → 磁盘I/O瓶颈（查iostat -x 1的%util和await）
- load高 + us高 + r高 → CPU真正打满（用pidstat -u 1 3找大户）
- load高 + sy高 + cs高 → 进程/线程切换频繁（常见于高并发锁竞争）
分步排查常用命令链
从警报出发，按顺序执行这几步，基本能覆盖90%的高负载场景：
- 确认负载与核心数：uptime && nproc
- 看整体状态：vmstat 1 5（盯r、b、wa、cs四列）
- 查I/O详情：iostat -x 1 3（重点关注%util接近100%或await＞10ms的设备）
- 找具体进程：iotop -o（只显示活跃I/O进程）或 ps aux --sort=-pcpu | head -10
- 验D状态进程：ps -eo stat,pid,comm | grep " D "（大量D状态=严重I/O卡顿）
