系统负载高需结合CPU、内存、I/O综合分析，Load Average反映任务排队情况，持续高于CPU核心数需排查；通过top、free、iostat等命令检查资源使用，定位高消耗进程并审查日志，部署监控系统实现告警与趋势分析，预防问题复发。
系统负载高是运维中常见问题，尤其在生产环境中可能直接影响服务可用性。Linux系统负载（Load Average）反映的是等待CPU资源的任务数量和正在运行的任务数，而非直接的CPU使用率。排查高负载原因需要结合多个工具和指标综合分析。
理解Load Average数值含义
执行uptime或top命令时，会看到类似load average: 4.50, 4.10, 3.80的信息：
- 第一个值：过去1分钟的平均负载
- 第二个值：过去5分钟的平均负载
- 第三个值：过去15分钟的平均负载
若系统为4核CPU，Load超过4即表示任务排队，可能存在瓶颈。持续高于CPU核心数需引起注意。
检查CPU、内存与I/O使用情况
高负载不一定由CPU导致，也可能是I/O等待或内存不足引发。
使用以下命令快速定位：
- top：查看整体资源使用，重点关注%Cpu(s)行中的wa（I/O等待）是否偏高
- htop（更直观）：可按CPU、内存排序进程
- free -h：检查内存使用和swap是否被大量使用
- iostat -x 1：观察磁盘I/O延迟，%util接近100%表示设备饱和
如果wa值高，说明进程在等待I/O完成，即使CPU空闲也会导致负载升高。
定位消耗资源的进程
找出具体“元凶”进程是解决问题的关键。
- 用ps aux --sort=-%cpu | head -10列出CPU占用最高的进程
- 用ps aux --sort=-%mem查看内存大户
- 结合pidstat 1 5定期采样进程资源使用
- 对于频繁读写磁盘的进程，可用iotop查看实时I/O情况
发现异常进程后，可通过日志（如/var/log/messages、应用日志）进一步判断其行为是否正常。
监控与长期预防
避免问题反复出现，建议建立监控机制。
- 部署Prometheus + Node Exporter收集系统指标
- 使用Grafana可视化Load、CPU、内存、I/O趋势
- 设置告警规则，例如Load > CPU核心数 × 1.5 时通知
- 定期审查系统日志和cron任务，防止定时任务引发负载突增
基本上就这些。掌握从现象到根源的排查路径，能快速应对大多数高负载场景。
