Linux高负载需综合判断，先看load average除以CPU核数是否≥1.0，再通过top、vmstat、iostat等定位CPU、内存、I/O或网络瓶颈，最后针对性优化。
Linux高负载不是单看CPU使用率高，而是系统整体“忙不过来”的综合表现。关键要区分：是CPU真忙？内存快撑爆？磁盘在死扛？还是网络卡在排队？下面从定位、归因、应对三步讲清楚，不绕弯子。
看懂负载值和CPU核心数的关系
执行 uptime 或 cat /proc/loadavg，你会看到类似 load average: 4.21, 3.89, 3.50 的三个数字——分别代表过去1、5、15分钟的平均负载。
别直接和100%比，要拿它除以CPU逻辑核数（nproc 或 grep -c 'processor' /proc/cpuinfo）：
- 负载 ÷ 核数 ＜ 0.7：基本健康
- 0.7 ≤ 负载 ÷ 核数 ＜ 1.0：需关注，可能有隐患
- ≥ 1.0：系统已过载，队列积压，响应延迟明显
- ≥ 2.0：严重过载，服务可能开始超时或失败
注意：短时峰值（比如1分钟负载突高但5/15分钟平稳）通常不用急；持续15分钟高于1.0才真正危险。
快速定位瓶颈类型
打开 top，第一眼盯三块：
-
%Cpu(s) 行：看
us（用户态）、sy（内核态）、wa（I/O等待）占比
→wa高（比如＞20%）：大概率是磁盘慢，不是CPU真忙 - load average 值本身是否远超核数
-
Mem 和 Swap 行：
available内存是否极少、usedswap 是否在增长
→ Swap 持续使用，说明物理内存不足，会拖垮整体性能
再补一条命令确认：vmstat 1 5 看 r（运行队列长度）、b（不可中断睡眠进程数）、wa（I/O等待），三者长期偏高就是典型高负载信号。
分方向查具体元凶
CPU密集型问题：
在 top 中按 P（大写P），看 %CPU 最高的几个进程；或用ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -10
内存/交换问题：free -h 看 available；再用ps -eo pid,%mem,cmd --sort=-%mem | head -10 找吃内存大户；
同时检查 dmesg | grep -i "oom\|kill"，看内核是否已触发OOM Killer杀进程。
I/O卡顿问题：iostat -x 1 关注三列：
→ %util 接近100%：磁盘饱和
→ await 显著大于 svctm：I/O响应慢、队列堆积
→ r/s + w/s 异常高：读写请求暴增
配合 iotop 可直接看到哪个进程在猛刷盘。
网络连接异常：ss -s 查总连接数和TCP状态分布；netstat -s | grep -i "retransmit\|drop\|overflow" 看丢包、重传、队列溢出等线索。
常见应对动作（不盲目重启）
找到元凶后，优先做最小干预：
- 临时终止非关键进程：
kill -15 PID（优雅退出），慎用-9 - 调整资源争抢：
renice -n 10 PID降低其CPU调度优先级 - 释放缓存（仅测试环境谨慎用）：
echo 3 > /proc/sys/vm/drop_caches - 限制进程资源：
cpulimit -p PID -l 50限CPU到50% - 查日志溯源：
journalctl -u your-service --since "1 hour ago" -n 50
长期稳定靠配置优化：比如数据库调buffer pool、应用加连接池、Nginx开gzip、日志轮转策略收紧、定期清理无用定时任务等。
基本上就这些。高负载排查本质是“缩小范围→聚焦指标→验证假设→快速止血”，工具只是眼睛，逻辑才是主线。
