救命！我的 Linux 系统好像在疯狂健身-优快云博客

本文链接：https://blog.youkuaiyun.com/cui_win/article/details/148167818

家人们谁懂啊！今天登录服务器一看，好家伙，这平均负载数值直接飙到两位数，我仿佛看见我的 Linux 系统正举着 CPU 杠铃疯狂撸铁，一边还喊着 “再来亿个进程！”
这平均负载到底是个什么神奇玩意儿？它就像系统的 “压力温度计”，不仅能告诉你这一秒系统有多忙，还能通过 1 分钟、5 分钟、15 分钟的 “压力曲线”，预测它会不会突然累到罢工。要是数值比 CPU 核心数还高，那就相当于系统在说：“救命！我被进程大军包围了！”
想知道你的系统是在摸鱼划水，还是在超负荷加班？快搬好小板凳，这篇文章手把手教你读懂系统的 “摸鱼日记”，顺便抢救一下那些被高负载逼疯的服务器！
别急着慌神！接下来咱们就从排查高负载的“罪魁祸首”开始，教你用几个超实用的Linux命令，像侦探破案一样揪出疯狂吃资源的进程，再给系统来一套“急救降压操”，让它重新变回那个轻松应对工作的“六边形战士”！

一、平均负载（Load Average）的含义

平均负载是 Linux 系统中衡量系统整体负载情况的关键指标，反映了系统在一段时间内处于 可运行状态（Runnable） 和不可中断状态（Uninterruptible） 的进程数量。通俗来说，它表示系统的“繁忙程度”，包括以下三个核心要点：

统计时间范围
- 系统会统计 1 分钟、5 分钟、15 分钟 三个时间窗口的平均负载值，分别对应系统的短期、中期、长期负载趋势。
- 例如，若输出为 0.50 0.60 0.70，表示过去 1 分钟、5 分钟、15 分钟的平均负载分别为 0.5、0.6、0.7。
可运行状态进程
- 指正在 CPU 上运行或等待 CPU 资源的进程（处于 R 状态，对应 CPU 密集型负载）。
不可中断状态进程
- 指正在执行 I/O 操作（如读写磁盘、网络请求）且无法被中断的进程（处于 D 状态，对应 I/O 密集型负载）。
与 CPU 核心数的关系
- 平均负载的“合理值”与系统 CPU 核心数密切相关：
  - 若平均负载 ≤ CPU 核心数，表示系统负载正常；
  - 若平均负载 > CPU 核心数，则意味着系统负载过高，可能存在性能瓶颈。
- 例如，4 核 CPU 的系统中，平均负载持续高于 4 时需警惕。

二、平均负载高的常见原因及分析

平均负载高通常由 CPU 资源不足、I/O 瓶颈或进程调度问题导致，以下是具体原因分类及排查方向：

（一）CPU 负载过高

现象：平均负载高，且 R 状态进程占比大，CPU 使用率高（可用 top/htop 查看）。
常见原因：

CPU 密集型进程
- 大量计算任务（如视频转码、科学计算、加密解密）导致 CPU 满负荷运行。
- 排查方法：
  - 使用 top 按 CPU% 排序，定位高 CPU 进程；
  - 通过 pstack <pid> 查看进程堆栈，分析是否存在死循环或算法效率低下问题。
进程数量过多
- 短时间内启动大量进程（如 Web 服务突发请求），超出 CPU 调度能力。
- 排查方法：
  - 检查进程启动脚本或服务（如 Docker 容器、定时任务）是否存在异常启动逻辑；
  - 使用 ps aux 查看进程状态，结合 systemd 或 supervisor 管理进程启停。
内核态 CPU 占用高
- 内核模块或中断处理程序（如网络、磁盘中断）占用大量 CPU 资源。
- 排查方法：
  - 使用 perf 工具分析内核函数调用栈（如 perf top -k）；
  - 检查硬件驱动是否存在兼容性问题（如网卡、SSD 驱动异常）。

（二）I/O 负载过高

现象：平均负载高，且 D 状态进程占比大，磁盘 I/O 等待率高（可用 iostat/pidstat 查看）。
常见原因：

磁盘性能瓶颈
- 机械硬盘（HDD）面对高随机 I/O 场景（如数据库写入）时性能不足，导致进程阻塞。
- 排查方法：
  - 使用 iostat -x 1 查看磁盘利用率（%util）、队列长度（await/svctm）；
  - 若 %util 持续高于 70% 或 await 远大于 svctm，可能需升级为 SSD 或优化 I/O 模式。
大量文件读写操作
- 日志写入、数据备份、文件传输（如 scp/rsync）等场景导致磁盘繁忙。
- 排查方法：
  - 使用 lsof 查看当前打开文件的进程；
  - 通过 iotop 实时监控进程的 I/O 吞吐量，定位异常进程。
内存不足引发 Swap 频繁交换
- 系统内存不足时，会将内存数据交换到磁盘（Swap），导致大量 I/O 操作。
- 排查方法：
  - 使用 free -h 查看内存使用情况，若 Swap 使用率高，需增加物理内存或优化内存占用；
  - 通过 top 查看 %swap 和 %mem，定位内存泄漏的进程（如长时间运行的服务未释放内存）。

（三）资源竞争与锁问题

现象：平均负载高，但 CPU 和 I/O 使用率未必满负荷，进程因等待资源而阻塞。
常见原因：

进程间竞争锁资源
- 多线程/多进程程序因锁竞争（如数据库行锁、文件锁）导致大量进程处于等待状态。
- 排查方法：
  - 使用 strace 跟踪进程系统调用，查看是否卡在 wait() 或 poll()；
  - 分析程序代码或数据库日志，优化锁粒度（如将表锁改为行锁）。
内核锁或调度器瓶颈
- 内核版本过低或调度器参数不合理（如 sched_min_granularity_ns），导致进程调度延迟。
- 排查方法：
  - 升级内核至稳定版本；
  - 通过 sysctl 调整调度器参数（如 vm.swappiness、net.core.somaxconn）。

（四）其他原因

网络问题
- 高并发网络请求导致 TCP 连接队列积压（如 netstat -s | grep listen 显示大量 SYN_RECV），引发进程阻塞。
- 排查方法：
  - 调整内核网络参数（如 tcp_max_syn_backlog、somaxconn）；
  - 使用 ss -ltn 查看监听端口状态，检查 Web 服务是否配置合理的连接数限制。
系统参数配置不合理
- 进程最大打开文件数（ulimit -n）、最大进程数（kernel.pid_max）等限制过低，导致进程无法正常创建或运行。
- 排查方法：
  - 通过 ulimit -a 查看当前限制，对比业务需求调整（如 Web 服务器需增大文件描述符限制）；
  - 修改 /etc/security/limits.conf 或内核参数（/etc/sysctl.conf）并重启生效。

三、排查平均负载高的通用流程

初步观察
- 使用 uptime 或 w 命令查看平均负载数值，判断是短期（1 分钟）还是长期（15 分钟）问题。
- 对比 CPU 核心数，确定负载是否超出正常范围（如 4 核 CPU 负载持续 >4）。
分类定位
- CPU 问题：用 top/htop 查看 %CPU 高的进程，结合 perf 分析调用栈。
- I/O 问题：用 iostat/iotop 查看磁盘利用率和进程 I/O 情况，检查 Swap 使用。
- 资源竞争：用 strace/lsof 跟踪进程状态，分析锁或文件句柄竞争。
深入分析
- 若怀疑硬件问题（如磁盘故障），使用 smartctl 检查磁盘健康状态；
- 若为软件问题，结合应用日志（如 Nginx、MySQL 慢查询日志）定位具体业务逻辑瓶颈。
优化与验证
- 根据原因调整参数、升级硬件或优化代码，重启服务后观察平均负载是否下降。