Linux高负载需看load average与CPU核心数比值是否超1，而非仅CPU使用率；CPU低但负载高时重点查I/O等待、inode耗尽；进程CPU高未必是问题，需结合业务场景判断；优先通过日志和时间线定位根因。
Linux高负载不能只看CPU使用率——很多新手一看到top里CPU才30%就松口气，结果uptime显示load average是12（8核机器），系统早已卡顿。真正关键的是“有多少进程在排队等资源”，而不仅是“CPU忙不忙”。下面从实操角度讲清排查路径和几个高频误区。
先看负载值本身是否真超标
别跳过这一步。执行：
-
uptime或cat /proc/loadavg查三个平均值（1/5/15分钟） -
nproc或grep -c 'processor' /proc/cpuinfo确认逻辑CPU核心数
判断标准不是“load > 1”，而是load / CPU核心数 > 1才表示过载。比如8核机器，load=10意味着平均有2个进程在等待运行——哪怕CPU空闲，系统响应也会变慢。
CPU低但负载高？重点查I/O等待
这是最典型的认知盲区。当top显示%Cpu(s): 12.3 us, 4.1 sy, 0.0 wa时，wa=0看起来很安全；但如果vmstat 1里r列长期＞CPU核数、b列非零，说明大量进程卡在I/O上，只是还没反映到wa统计里。
- 用
iostat -x 1看%util和await：>90%或>10ms需警惕 - 用
iotop -o找实际刷盘的进程（不是所有高IO都显现在top里） - 检查
df -i：inode耗尽也会导致open/write阻塞，现象类似高负载
别把“进程CPU高”直接等同于“问题代码”
看到某个Java进程占了80% CPU，第一反应不该是杀掉或改代码，而是确认它是否本该如此。比如：
- 批量导出报表的定时任务，在凌晨跑30分钟占满CPU是合理的
- 刚上线的新服务，因缓存未预热，首次查询触发大量计算，可能只是暂时现象
- 用
pwdx PID确认进程归属路径，再结合业务排期判断是否符合预期
真要深挖代码层，对Java应用推荐用show-busy-java-threads.sh一键定位热点线程，比手动jstack + vim + printf快得多，也避免漏掉GC线程或锁竞争场景。
日志和时间点比实时指标更有说服力
负载飙升往往有规律。不要只盯着当前top，花2分钟做这几件事：
- 查
dmesg -T | tail -30：OOM killer是否干掉过进程？磁盘错误是否频繁？ - 看
/var/log/messages或journalctl --since "2 hours ago"：有没有配置变更、crontab执行、备份脚本启动？ - 对比监控图（如果有）：负载峰值是否和某次发布、某张大表DDL、某个定时job完全重合？
多数线上高负载问题，根因不在内核参数或硬件，而在“谁在什么时间触发了什么操作”。还原时间线，比调优单个命令有效十倍。
基本上就这些。不复杂，但容易忽略。
