load average 异常需对比 cpu 逻辑核心数：≤核心数正常；持续＞1.5×核心数需关注，＞2×核心数大概率有瓶颈；1分钟值远高于15分钟值提示刚发生尖峰，15分钟值高而1分钟值低则可能缓慢堆积。
怎么看 load average 数值是否异常
直接看 uptime 或 top 第一行的三个数字（如 load average: 2.45, 1.89, 1.32），它们分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。这不是 CPU 使用率百分比，而是「等待 CPU 或不可中断 IO（D 状态）的进程平均数量」。
- 数值 ≤ CPU 逻辑核心数（可用
nproc查）：系统宽松，一般没问题 - 数值持续 > 1.5 × 核心数：需关注；> 2 × 核心数：大概率存在瓶颈
- 特别警惕“1 分钟值远高于 15 分钟值”（如
7.2, 2.1, 1.9）：说明刚爆发过尖峰，可能已过去，但得立刻查当时在跑什么 - 反过来，15 分钟值高而 1 分钟低（如
0.8, 1.5, 3.6）：负载正在缓慢堆积，可能是内存泄漏或慢查询积累
为什么 top 显示 CPU 使用率不高，load 却很高
这是最常让人困惑的情况——%Cpu(s): 32.1 us, 4.2 sy, 0.0 ni, 63.5 id, 0.2 wa 看着很闲，但 load average: 8.6, 7.9, 7.2 却压在 8 以上。根本原因在于：load 统计的是「就绪队列 + 不可中断睡眠（D 状态）进程数」，而 CPU 使用率只算真正执行指令的时间。
- 典型诱因是磁盘 IO 卡住：进程在等磁盘读写完成（
D状态），不消耗 CPU，但计入 load - 用
iostat -x 1看%util和await：若%util接近 100% 或await> 50ms，基本锁定 IO 瓶颈 - 用
ps aux --sort=-pcpu | head -10检查有没有大量D状态进程（STAT 列含D） - 注意：NVMe 盘的
%util解读和 SATA 不同，高 util 不一定代表真瓶颈，要结合avgqu-sz（平均队列深度）一起看
uptime 的 load 值从哪来？能直接读 /proc 吗
能，而且更轻量。Linux 内核把实时 load 值维护在 /proc/loadavg，uptime 就是读它。执行 cat /proc/loadavg 输出形如 3.21 2.88 2.65 3/124 12345，前三个是 load，第四个 3/124 表示「当前有 3 个可运行进程，系统共 124 个进程」，最后是最近创建的进程 PID。
- 脚本中建议直接读
/proc/loadavg而非调uptime，避免 fork 新进程、解析字符串的开销 - 注意：该文件无锁，多核下瞬时读取可能存在微小不一致，但对监控告警完全够用
- 不要误以为第四个数（如
3/124中的124）是总线程数——它包含所有状态的 task_struct，包括僵尸进程
单核高负载但其他核空闲？mpstat 要这样用
当整体 load 高、CPU 总使用率却不突出时，大概率是某个核心被独占。这时 top 默认聚合显示会掩盖问题，必须用 mpstat 拆开看每颗核。
- 运行
mpstat -P ALL 1 3：每秒采样一次，共三次，输出每颗逻辑 CPU 的详细占用 - 重点看
%usr+%sys是否某颗核长期 >90%，而其他核 - 常见陷阱：容器环境里
mpstat -P ALL显示的 CPU 编号是宿主机视角，和docker stats或 cgroup 的 cpuacct.stat 不对应，排查时要确认命名空间上下文 - 如果发现某核持续 100%，用
pidstat -t -p <pid> 1</pid>追踪该进程下的线程级 CPU 分布，定位热点线程
