Linux高负载时应先看load average、CPU使用率、IO等待时间三指标；load average表示运行态或不可中断睡眠态进程平均数，非CPU百分比；load高而CPU低且iowait%>20%表明IO瓶颈；内存不足会引发swap和page cache回收，导致高load与sy%飙升。
Linux高负载时，第一反应不是重启服务，而是快速定位“谁在吃CPU、内存或IO”。关键看三个指标：load average（系统平均负载）、CPU使用率、IO等待时间。三者不一致时，往往能直接锁定问题类型。
看懂 load average 的真实含义
执行 uptime 或 top，看到类似 load average: 12.45, 11.88, 10.23 —— 这不是CPU使用率百分比，而是**过去1/5/15分钟内，处于运行态或不可中断睡眠态（如磁盘IO）的平均进程数**。重点对比：如果 CPU 核心数是 8，load 长期 > 8，说明有进程排队；若 load 高但 CPU 使用率很低（
- 用
ps aux | awk '$8 ~ /D/ {print}'快速找 D 状态进程 - 用
cat /proc/loadavg查看更细粒度：第4字段是当前运行队列长度，第5字段是总进程数
揪出 CPU 消耗大户
top 默认按 CPU 排序，但容易漏掉短时爆发型进程。建议组合使用：
-
top -Hp [PID]查看某进程的各线程占用（尤其 Java 应用常见单线程打满） -
pidstat -u 1 3每秒采样3次，精准捕捉波动峰值 - 对 Java 进程，用
jstack [PID] > jstack.log结合top -Hp找到高 CPU 线程 ID，转为十六进制后在 jstack 日志里搜nid=0x...定位具体方法栈
识别隐形 IO 卡顿元凶
当 load 高、CPU 低、iowait%（top 第三行右数第二项）持续 >20%，说明磁盘慢或进程卡在 IO。别只盯 iotop——它显示的是“当前正在读写”的进程，而真正拖慢系统的可能是大量 同步写等待（比如日志刷盘、数据库 fsync）。
- 用
iostat -x 1关注%util（设备忙时百分比）和await（IO 平均响应时间，>10ms 要警惕，>50ms 通常已严重） - 查
/proc/[PID]/io看某进程累计读写字节数和 syscalls 次数，判断是否频繁小 IO - 检查磁盘健康：
smartctl -a /dev/sda，关注 Reallocated_Sector_Ct、Pending_Sector 等字段
内存不足引发的连锁假象
内存吃紧时，系统会频繁 swap 和回收 page cache，导致大量 IO 和上下文切换，表现常为 load 高 + CPU sy%（系统态）飙升 + kswapd0 进程活跃。此时 free -h 可能显示 “available” 不足，但 buff/cache 很高——别急着 kill 进程，先看是否被 page cache 占用（可安全释放）。
-
echo 1 > /proc/sys/vm/drop_caches（仅临时测试，生产慎用）验证 cache 是否真成瓶颈 - 用
slabtop查看内核 slab 分配，dmesg -T | grep -i "out of memory"确认是否 OOM Killer 已介入 - 对容器环境，检查
cgroups内存限制：cat /sys/fs/cgroup/memory/.../memory.usage_in_bytes
基本上就这些。高负载排查不是拼命令数量，而是建立“load → CPU/IO/MEM → 进程/线程/内核态”的归因链条。每次动手前，先花30秒看全 top 屏幕，比盲目杀进程有效得多。
