Linux CPU负载是单位时间活跃进程（R/D状态）平均数，反映系统任务压力而非CPU使用率；uptime显示1/5/15分钟负载，需对比逻辑CPU数判断：≈线程数为满载，>则排队承压，
Linux 的 CPU 负载（load average）不是 CPU 使用率，而是单位时间内系统中“活跃进程”的平均数量——包括正在运行的、等待 CPU 的（R 状态），以及因等待 I/O 而不可中断的（D 状态）进程。它反映的是系统整体任务压力，而不是 CPU 核心忙不忙。
怎么看负载数值？
执行 uptime 或 top 命令，会看到类似这样的输出：
load average: 1.25, 0.87, 0.42
这三个数字分别代表最近 1 分钟、5 分钟、15 分钟 的平均负载。重点看后两个（5/15 分钟），它们更稳定，能反映持续压力趋势。
关键不是绝对值大小，而是和你的 CPU 总线程数对比：
- 用 nproc 或 grep -c 'processor' /proc/cpuinfo 查出逻辑 CPU 数（比如 8 核 16 线程 → 得到 16）
- 负载 ≈ 16：CPU 基本满负荷
- 负载 > 16：有进程在排队等资源，系统开始承压
- 负载
负载高 ≠ CPU 使用率高
这是最容易误解的一点。举几个典型场景：
- CPU 密集型任务（如科学计算）：负载升高 + CPU 使用率也高（us/sy 高）
- I/O 密集型任务（如大量磁盘读写）：进程卡在 D 状态等磁盘响应，负载升高，但 %wa（iowait）高、%us 可能很低
- 大量短生命周期进程（如频繁 fork/exec）：上下文切换剧烈，cs（context switch）飙升、%sy 升高，负载高，但单个进程不占 CPU 很久
所以仅看 top 里的 %CPU 不足以判断问题根源，必须结合负载值和 vmstat、iostat 等工具交叉验证。
快速定位高负载原因
按顺序执行这几步，能高效缩小范围：
-
查负载和 CPU 数：
uptime && nproc -
看实时进程分布：
top -o %CPU（找 CPU 消耗大户）或ps -eo pid,ppid,%cpu,%mem,comm --sort=-%cpu | head -10 -
查 I/O 是否拖累：
iostat -x 1 3关注 %util（设备利用率）、await（I/O 平均等待时间）、r/s+w/s（每秒读写次数） -
查上下文切换：
vmstat 1看 cs 列（每秒上下文切换次数），若远超 10k，可能有进程风暴或中断异常 -
查不可中断进程：
ps aux | awk '$8 ~ /D/ {print}'—— 如果大量 D 状态，大概率是存储或驱动问题
什么时候该警惕？
不必一看到负载 >1 就紧张，要结合业务节奏和历史基线判断：
- 负载持续 > CPU 线程数 × 1.5，且 15 分钟值未回落 → 值得深入排查
- 1 分钟负载突然冲高（如 12.0），但 5/15 分钟仍低（如 0.3, 0.2）→ 短时毛刺，可观察
- 负载高 + %wa > 30% → 优先查磁盘、NFS、数据库慢查询
- 负载高 + %sy > 25% 且 cs > 20k → 查是否有异常内核模块、网络软中断、或 fork 炸弹
