linux高负载需综合评估 load average 与 CPU 核心数比值，关注 wa 值区分 CPU 或 I / O 瓶颈，并分层定位、溯源代码 / 配置，最后验证优化效果并告警防复发。
Linux 高负载不是“CPU 跑满”那么简单，它反映的是系统整体资源调度压力。关键要看 load average 是否持续超过 CPU 核心数的 0.7 倍——比如 4 核机器，长期负载>2.8 就要警惕；若>6，通常已影响服务响应。
一、先看整体：快速判断负载性质
执行 uptime 或top，重点读三行：
- load average: 2.45, 1.98, 1.72 —— 对比
nproc结果（如为 4），当前 1 分钟负载 2.45 ÷ 4 ≈ 0.61，尚可；但若升至 5.2，就明显过载 - %Cpu(s): 12.3 us, 8.5 sy, 0.0 wa, 79.2 id —— us+sy 高 + wa≈0 → CPU 密集型；wa>10% → I/ O 等待严重
- KiB Mem / KiB Swap —— swap used 持续增长，可能内存不足触发换页
二、分层定位：按资源类型逐项排查
CPU 型高负载 ：
用pidstat -u 1找 CPU 消耗 TOP 进程；对 java 类服务，再用 top -Hp $PID + jstack $PID | grep -A 20 '0x$(printf "%x" $TID)' 定位 热点 方法。
I/ O 型高负载 ：
运行 iostat -x 1 看%util是否接近 100%，await是否飙升；再用 iotop -o 直击正在刷盘的进程。
内存型高负载 ：free -h 看 available 是否过低；dmesg | grep -i "killed process"确认是否 OOM Killer 已介入杀进程。
三、查进程根源：别只盯 PID，要追到代码 / 配置
找到高负载进程后，别急着 kill：
- 用
pwdx $PID看工作目录，常能识别服务归属（如/opt/app/web） - 用
cat /proc/$PID/cmdline | tr ' ' ' '还原完整启动命令，确认是否带了异常参数 - 检查日志路径（
ls -l /proc/$PID/fd/ | grep log），翻最近错误或慢查询 - 如果是定时任务，查
crontab -l和/etc/cron.d/下是否有高频或未收敛脚本
四、验证与收尾：确认解决，防复发
优化后观察 5–15 分钟负载趋势：
- 用
watch -n 2 'uptime; echo "---"; mpstat -P ALL 1 1 | tail -4'持续盯核心指标 - 写个简单监控脚本，当
load / $(nproc) > 0.75时发告警（可用mail或curl调用企业 微信hook） - 记录本次根因：是某个 sql 没走索引？是日志轮转配置错误？还是上游突发流量？归档进团队知识库
基本上就这些。不复杂但容易忽略——多数高负载问题，其实卡在第一步“没看清 wa 值”或“误把 I / O 等待当 CPU 忙”。
