linux高负载需结合CPU核心数判断是否真过载，再通过uptime、top、iostat、vmstat等工具区分CPU型、I/O型或混合型问题，逐层定位进程、线程及隐藏干扰项。
Linux高负载不能只看uptime里那三个数字，得结合CPU核心数判断是否真过载，再分方向快速锁定是CPU、内存、磁盘IO还是网络拖了后腿。
先看负载值是否真超标
运行uptime或cat /proc/loadavg，拿到1/5/15分钟平均负载。关键不是数字本身，而是和CPU核心数比：
- 查核心数：
grep -c 'processor' /proc/cpuinfo或nproc - 合理上限 ≈ 核心数 × 0.7（比如4核机器，负载超2.8就该看了）
- 若1分钟值远高于15分钟值，说明刚爆发问题，优先盯当前
- 负载高但CPU idle仍高？很可能是I/O等待导致的“假忙”
区分负载类型：CPU型 or I/O型
同一高负载，原因可能截然不同：
- CPU型：top里%CPU总和高，
mpstat -P ALL 1显示某核持续95%+，vmstat中us+sy占比大，wa很低 - I/O型：top里CPU使用率不高，但
iostat -x 1中%util接近100%，vmstat中wa常超30%，r队列长度持续≥4 - 混合型：用
pidstat -u 1 -d 1同时看进程CPU和IO，找双高进程
逐层定位具体进程和线程
找到“罪魁”才能对症下药：
- 按CPU排序：
ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -10 - 按内存排序：
ps -eo pid,ppid,%mem,%cpu,cmd --sort=-%mem | head -10 - 查IO大户：
iotop -o（只显示实际在读写的进程） - java类服务可进一步：
top -H -p $PID找高耗线程，再用jstack $PID看堆栈 - 确认进程归属：
ls -l /proc/$PID/exe或cat /proc/$PID/cmdline
别漏掉隐藏干扰项
有些问题不在进程表里，却实实在在推高负载：
- 磁盘空间满：
df -h和df -i（inode耗尽也会卡死） - 异常定时任务：
crontab -l和systemctl list-timers --all - 内核级报错：
dmesg -T | tail -30看OOM、硬件错误或时间跳变 - 突发网络连接：
ss -s查总连接数，nethogs看实时带宽归属 - 文件描述符耗尽：
lsof -n | awk '{print $2}' | sort | uniq -c | sort -nr | head
基本上就这些。不复杂但容易忽略——尤其是把load avg和CPU使用率混为一谈，或者只盯top不看iostat。养成先判类型、再锁进程、最后查上下文的习惯，排查效率能翻倍。