Linux高负载如何排查_常见误区解析避免新手踩坑【教学】

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 完全重合？

多数线上高负载问题，根因不在内核参数或硬件，而在“谁在什么时间触发了什么操作”。还原时间线，比调优单个命令有效十倍。

基本上就这些。不复杂，但容易忽略。