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 '\0' ' '还原完整启动命令，确认是否带了异常参数 - 检查日志路径（
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忙”。
