Linux高负载需先看负载值是否越界，再结合CPU、I/O、内存、进程四方面交叉验证；重点关注loadavg三值与核心数关系，区分CPU型（%wa低）与I/O型（%wa高），用mpstat、iostat、pidstat等工具定位瓶颈。
Linux高负载不是“CPU使用率高”那么简单，它反映的是系统整体就绪队列的繁忙程度。真正关键的是：先看负载值是否越界，再结合 CPU、I/O、内存、进程四方面交叉验证，避免误判。
一、快速确认负载是否异常
执行 uptime 或 cat /proc/loadavg，重点关注三个平均值（1/5/15分钟）：
- 查 CPU 核心数：nproc 或 grep -c 'processor' /proc/cpuinfo
- 合理阈值参考：负载 > 核心数 × 0.7 就该警惕；> 核心数 × 1.5 通常已影响服务响应
- 若 1 分钟负载远高于 15 分钟（如 8.2 vs 1.3），说明突发压力刚发生，需立即介入
二、区分是 CPU 型还是 I/O 型高负载
仅看 top 里的 %CPU 容易漏掉真相。重点看 %wa（iowait） 和各指标组合：
- CPU 高 + %wa 低（：典型 CPU 密集型，用 mpstat -P ALL 1 3 看哪颗核打满，再用 pidstat -u 1 找高 CPU 进程
- 负载高 + %CPU 低 + %wa 高（>10%）：I/O 瓶颈，立刻运行 iostat -x 1 3 查 %util 是否接近 100%，再用 iotop 定位读写大户
- vmstat 1 5 中 r 值持续 > 核心数：就绪队列堆积，说明任务太多或响应太慢，需结合上面两类深挖
三、精准定位“搞事情”的进程和线程
找到罪魁祸首只是第一步，得锁定具体行为：
- 对高 CPU 进程（如 PID=1234），用 top -Hp 1234 找出最耗 CPU 的线程 TID
- Java 应用：把 TID 转为十六进制（printf "%x\n" TID），再用 jstack PID | grep -A10 HEX_TID 查堆栈
- 通用深度追踪：用 sudo strace -tt -T -p PID -o /tmp/trace.log 捕获系统调用，看是否卡在 open/read/write/futex 等调用上
- 怀疑内存或缓存问题：检查 free -h 中 available 是否过低，dmesg | grep -i oom 看是否触发过杀进程
四、常见陷阱与应对建议
很多排查卡在“看起来正常，但就是慢”，往往是以下原因：
- 单核打满但整体 CPU 使用率不高 → 用 mpstat -P ALL 1 看各核分布，别只信汇总值
- 进程显示 sleep 状态却拉高 load → 很可能是 D 状态（不可中断睡眠），多由磁盘或 NFS 卡住导致，ps aux | awk '$8 ~ /D/ {print}' 可筛选
- 负载高但 iostat 无异常 → 检查网络 IO，用 iftop 或 nethogs 看是否有进程疯狂发包或建连接
- 临时缓解可尝试：echo 1 > /proc/sys/vm/drop_caches（仅清页缓存，慎用）、限制进程资源（cpulimit 或 cgroup）
基本上就这些。核心逻辑始终是：看负载数值 → 判定瓶颈类型 → 锁定具体进程/线程 → 分析行为根源。不复杂但容易忽略细节。
