linux高负载需按“负载值→资源类型→进程→线程→调用链”逐层排查：先比对负载与 CPU 核心数（阈值 = 核数×0.7），再用 mpstat/iostat/pidstat 区分 CPU 型或 I / O 型，接着用 strace/jstack 定位线程级瓶颈，最后检查内存与 swap 影响。
Linux 高负载不是“CPU 用满了”那么简单——它反映的是系统整体任务队列的积压程度。真正关键的是：先看负载值是否越界，再分清是 CPU 忙、IO 堵、内存缺，还是进程卡在系统调用里。定位准了，修复才快。
一、确认负载是否真超标
别只盯着 uptime 或top里那个数字。先查 CPU 核心数：
-
grep -c 'processor' /proc/cpuinfo或nproc - 合理阈值 = 核心数 × 0.7（比如 8 核，负载持续>5.6 就要查）
- 重点看三个值：
load average: 12.4, 9.8, 7.2—— 若 1 分钟值远高于 15 分钟值，说明突发尖峰；若三者都高且平稳，大概率是长期瓶颈
二、区分负载类型：CPU 型 vs I/ O 型
高负载但 CPU 使用率低？大概率是 I / O 卡住了。反过来，CPU 使用率飙高 + 负载高，才是计算密集问题。
- CPU 型：用
mpstat -P ALL 1 3看各核 %idle 是否接近 0；再用pidstat -u 1找出 %CPU 最高的进程 - I/ O 型：用
iostat -x 1 3看 %util 是否持续>90%，同时 %wa（iowait）是否>10%；再用iotop -o找实际在刷盘的进程 - 混合型：
pidstat -u 1 -d 1可同时输出 CPU 和 IO 指标，一眼比对
三、快速定位“元凶”进程
找到高消耗进程只是第一步，得往下挖一层——是哪个线程、哪段代码、甚至哪个系统调用在拖慢它。
- 对 java 进程：用
top -Hp [PID]找到高 CPU 线程 TID，转成十六进制（printf "%xn" [TID]），再用jstack [PID] | grep -A10 [hex]定位 堆栈 - 对任意进程：用
strace -p [PID] -tt -T -f -o /tmp/trace.log捕获系统调用耗时，重点关注反复出现的read、write、futex、epoll_wait等长耗时调用 - 如果进程卡在 D 状态（不可中断睡眠），基本可断定是磁盘或驱动层问题，
ls /proc/[PID]/stack能看到内核 栈
四、别忽略内存与交换的影响
表面看是 CPU 或 IO 问题，背后常是内存不足触发了 OOM Killer 或频繁 swap，导致大量进程排队等待页回收。
- 用
free -h看 available 是否严重偏低；用cat /proc/meminfo | grep -E "^(MemAvailable|SwapTotal|SwapFree|PageIn|PageOut)"查交换活动 - 运行
dmesg -T | grep -i "killed process"确认是否有进程被 OOM Killer 干掉 - 观察
vmstat 1 5中的si/so（swap in/out）和pgmajfault（主缺页次数），若数值持续非零，说明内存压力真实存在
基本上就这些。排查不是靠猜，而是按“负载值→资源类型→进程→线程→调用链”逐层收窄。工具 不用全记，但 mpstat、iostat、pidstat、strace 这四个组合，覆盖 90% 的高负载场景。
