Linux 系统负载过高排查思路与实战（11 步标准流程 + 6 场景修复手册）

来源：马哥Linux运维（微信公众号）| 发布日期：2026-09-06 定位：「负载高」全场景的端到端 runbook——11 步标准流程（确认异常→CPU→内存→磁盘→网络→进程状态→定位→分析→修复→验证→复盘）+ 6 大场景修复手册（临时措施/根本措施/风险提醒三段式）+ 命令速查/配置示例/回滚方案。Load Average 概念与车道模型见 linux-load-average-guide，Load 高但 CPU 低的专用决策树见 linux-load-high-cpu-low-troubleshooting，Netflix 60 秒快速分诊见 linux-server-load-case-study。

生产环境最常遇到的运维场景之一就是服务器负载突然飙升，业务响应变慢甚至不可用：监控频繁报警 Load Average 过高，SSH 登录都卡顿。Load Average 高不一定等于 CPU 使用率高，也不一定是内存不足——真实原因可能是磁盘 IO 瓶颈、网络流量暴增、僵尸进程堆积、软中断过高、内核任务卡死等。排查负载问题必须建立完整的观察链路和判断逻辑，避免盲目重启服务或凭感觉调参数。

一、Load Average 核心概念

Load Average 表示特定时间段内处于可运行状态（R）和不可中断睡眠状态（D）的平均进程数，三个数值分别对应过去 1/5/15 分钟：

uptime
# 输出示例： 14:23:45 up 10 days, 3:15, 2 users, load average: 2.35, 1.80, 1.50

• R 状态进程：Running 或 Runnable，正在使用 CPU 或等待 CPU 调度
• D 状态进程：不可中断睡眠（Uninterruptible Sleep），通常在等 IO（磁盘读写、NFS 挂载卡死）。这类进程无法被信号中断、无法被 kill，只能等 IO 完成或重启系统

多高算高（结合 CPU 核心数的经验值）：

例：4 核服务器 Load 3 以下正常、4-6 需排查、超过 8 严重拥堵。这只是经验值，还要结合业务特点和历史基线判断。

Load 高的 9 类可能原因： CPU 密集任务过多 / 磁盘 IO 瓶颈 / 网络 IO 高 / 内存不足触发 swap / 软中断过高 / 僵尸进程堆积 / 内核任务卡死 / NFS、CIFS 等远程文件系统挂载异常 / 驱动或硬件故障。

排查五原则： 先整体后局部 → 先观察后操作 → 先排除明显问题（CPU/内存/磁盘/网络四大资源）→ 先非侵入后侵入（优先查看类命令，避免一上来就重启）→ 记录现场（保存关键命令输出便于复盘）。

二、11 步标准排查流程

确认负载异常 → 检查 CPU → 检查内存 → 检查磁盘 IO → 检查网络 → 检查进程状态分布 → 定位具体进程 → 分析进程行为 → 采取修复措施 → 验证效果 → 复盘总结

步骤 1：确认负载确实异常

uptime
# 14:30:12 up 10 days,  3:21,  2 users,  load average: 8.56, 7.23, 6.10
grep -c processor /proc/cpuinfo   # 或 nproc

• 1 分钟值远高于 5/15 分钟值 → 突发性问题
• 三个值都很高且持续上升 → 持续性问题
• 负载超过核心数 2 倍 → 严重拥堵（如 4 核 Load 8.56 = 平均有 8.56 个进程在等 CPU 或 IO）

步骤 2：检查 CPU 使用情况

top
# 重点看 %Cpu(s) 行：
# %Cpu(s): 85.2 us, 10.5 sy,  0.0 ni,  2.3 id,  1.5 wa,  0.0 hi,  0.5 si,  0.0 st

分支： CPU 高 → 跳步骤 7 定位进程；wa 高 → 步骤 4 查磁盘；CPU 不高但 Load 高 → 步骤 3 查内存。

步骤 3：检查内存使用情况

free -h
#              total  used  free  shared  buff/cache  available
# Mem:          7.6G  5.2G  200M    100M        2.2G       2.1G
# Swap:         2.0G  1.8G        200M
vmstat 1 5
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache    si   so    bi    bo   in   cs  us sy id wa st
#  3  2 1843200 204800 102400 2252800  5120 3840  1024  2048 8000 12000 65 20 10  5  0

• 异常信号：Swap 使用率 > 50%、available < 500M、used 接近 total；si = 每秒从 swap 读入内存的数据量(KB)、so = 每秒从内存写入 swap 的数据量(KB)，si/so 持续不为 0 且数值较大 → 频繁 swap 严重拖慢系统
• 确认内存不足后：定位占用内存最多的进程 → 考虑扩容 / 优化应用内存 / 调整 swap 策略 → 步骤 7

步骤 4：检查磁盘 IO 情况

iostat -x 1 5
# Device  r/s    w/s   rkB/s   wkB/s  ...  r_await w_await aqu-sz  svctm  %util
# sda    50.2  120.5   2048.3  4096.7  ...    15.3    25.6   3.25    8.5  95.2
iotop -o    # 只显示正在进行 IO 的进程
# Total DISK READ: 50.2 M/s | Total DISK WRITE: 80.5 M/s
# TID  PRIO  USER   DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
# 1234 be/4  mysql    30.5 M/s    50.2 M/s  0.00 %  85.23 %  mysqld
# 5678 be/4  root     15.3 M/s    20.1 M/s  0.00 %  45.67 %  rsync
# → mysqld 和 rsync 在进行大量磁盘 IO

IO 排查深挖见 linux-disk-io-troubleshoot（%util 陷阱与 await 真相）与 linux-disk-io-monitoring-reference。

步骤 5：检查网络流量

sar -n DEV 1 5
# 14:35:02  IFACE  rxpck/s   txpck/s   rxkB/s   txkB/s
# 14:35:02  eth0   15234.50  18567.20  45678.30 67890.50
cat /proc/softirqs    # 关注 NET_RX / NET_TX 行（网络接收/发送的软中断次数）

• rxpck/s = 每秒接收的数据包数、txpck/s = 每秒发送的数据包数、rxkB/s / txkB/s = 每秒收/发数据量(KB)
• 异常信号：收发包数超过 10 万/秒、流量接近带宽上限、流量突然暴增
• 软中断确认：/proc/softirqs 中 NET_RX/NET_TX 持续快速增长，或 top 的 si > 20%

步骤 6：检查进程状态分布

ps -eo stat | sort | uniq -c | sort -rn
#   45 S
#   12 R
#    8 D
#    5 I
#    2 Z

进程状态机与 wchan/stack 深挖见 linux-process-state-diagnosis。

步骤 7：定位具体进程

top -bn1          # P 按 CPU 排序、M 按内存排序
ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20
ps aux | awk '$8 ~ /D/ {print $0}'   # 所有 D 状态进程
ps aux | awk '$8 ~ /Z/ {print $0}'   # 所有僵尸进程

异常信号：某进程 CPU 长期 > 80%、内存 > 50%、多个 D 状态、大量僵尸。记录 PID/用户/命令/资源占用。

步骤 8：分析进程行为

lsof -p <PID>              # 打开的文件/socket/设备：句柄泄漏？远程文件系统？
strace -p <PID> -c -f      # 系统调用统计（-c 统计调用次数和耗时，-f 跟踪子进程），Ctrl+C 后输出结果
pstack <PID>               # 函数调用堆栈：卡在哪个函数
cat /proc/<PID>/io         # IO 统计（rchar 读取的字符数 / wchar 写入的字符数 / read_bytes 实际磁盘读 / write_bytes 实际磁盘写）
lsof -i -a -p <PID>        # 网络连接（或 netstat/ss -antp | grep <PID>）
ps -eLf | grep <PID>       # 线程（或 top -H -p <PID>，-H 显示线程）

strace 输出判读：read/write 占比很高且耗时长 → 大量 IO 操作；futex/epoll_wait 占比高 → 等锁或等事件。

综合判断：大量磁盘 IO → 日志写入/数据库查询/文件操作；大量网络 IO → 请求/传输；CPU 高但系统调用不多 → 计算密集型任务；有大量网络连接 → 连接池耗尽、连接泄漏；打开大量文件 → 文件句柄泄漏。

步骤 9：采取修复措施

见第三节「6 场景修复手册」——每个场景都按 临时措施 → 风险提醒 → 根本措施 三段执行。

步骤 10：验证效果

uptime && top && free -h && iostat -x 1 5 && sar -n DEV 1 5
ps -eo stat | sort | uniq -c | sort -rn

通过标准：Load 下降到正常范围、CPU idle 上升、磁盘 %util 下降、swap 使用率下降、D 状态进程减少。负载仍高 → 回到步骤 2 重新排查（可能还有其他根因）。

步骤 11：复盘总结

复盘要点：触发时间与表现、告警内容、排查路径与关键命令、根因、修复措施、验证结果、是否需优化告警/应用架构/扩容升级。输出故障报告或知识库文档：问题描述 / 影响范围 / 根因分析 / 修复措施 / 预防措施 / 经验教训。

三、6 场景修复手册（临时措施 → 风险提醒 → 根本措施）

场景 1：某进程 CPU 占用过高

renice +10 -p <PID>   # 临时：降低调度优先级，让其他进程有更多机会获得 CPU

⚠️ renice 只是临时缓解，不能解决根本问题；直接 kill 需确认业务影响和重启方案。 根本措施：优化应用代码（死循环/频繁计算）、限流降级熔断等保护机制、扩容或负载均衡。

场景 2：内存不足导致频繁 swap

sync && echo 3 > /proc/sys/vm/drop_caches   # 临时：sync 确保脏页写入磁盘，echo 3 清理 page cache、dentries 和 inodes

⚠️ 清理缓存会导致后续文件 IO 变慢（需重新从磁盘读取文件到内存），正在进行的 IO 操作可能受影响，数据库性能短时下降；生产环境慎用，仅在内存极度紧张且确认缓存占用过多时、业务低峰期使用。

根本措施（含 swap 策略调整）：

cat /proc/sys/vm/swappiness     # 默认值通常是 60
echo 10 > /proc/sys/vm/swappiness                        # 临时调小
echo "vm.swappiness = 10" >> /etc/sysctl.conf && sysctl -p   # 永久

swappiness 值越小，系统越倾向于使用物理内存而不是 swap；设置过低可能导致内存不足时系统反而更慢。

场景 3：磁盘 IO 瓶颈

ionice -c3 -p <PID>   # 临时：Idle 调度类，没有其他 IO 请求时才执行

临时：暂停或限速大文件操作、备份任务、日志归档等。 根本措施：优化应用 IO 模式减少随机读写、使用 SSD 代替机械硬盘、增加磁盘缓存、检查文件系统碎片、检查慢查询导致数据库 IO 过高、检查日志轮转配置避免单个日志文件过大。深挖见 linux-disk-io-tuning。

场景 4：网络流量过大导致软中断高

# 临时：限制流量或暂停非关键服务
# 根本：启用网卡多队列
ethtool -l eth0              # 查看队列数（Pre-set maximums Combined: 4 / Current: 1）
ethtool -L eth0 combined 4   # 设置为最大队列数

# 启用 RPS（Receive Packet Steering，软件分发）
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus   # CPU 掩码 0xf = CPU 0-3

# 启用 RFS（Receive Flow Steering）
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries   # 全局流表
echo 2048 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt # 每队列流表

另：优化应用网络模型减少短连接、考虑使用负载均衡分散流量。单队列软中断热点案例复盘见 system-load-high-rsyslogd-case-study。

场景 5：D 状态进程堆积

常见原因： 磁盘故障或慢盘、NFS 挂载超时卡死、iSCSI 存储异常、驱动或内核 bug。

cat /proc/<PID>/stack   # 查看 D 状态进程内核堆栈
# [] wait_on_page_bit_common+0x123/0x456
# [] __filemap_get_folio+0x234/0x567
# [] ext4_write_begin+0x345/0x678
# [] generic_perform_write+0x456/0x789
# ... [] entry_SYSCALL_64_after_hwframe+0x234/0x567
# → 进程卡在文件写入操作上

# 临时（NFS 问题）：强制卸载
umount -f /mnt/nfs    # -f 强制
umount -l /mnt/nfs    # -l 延迟卸载

⚠️ -f 表示强制卸载、-l 表示延迟卸载，强制卸载可能导致数据丢失，慎用；D 状态进程无法清理时可能只能重启系统。 根本措施：smartctl -a /dev/sda 查磁盘健康状态、检查 NFS 配置和网络连接、检查存储设备是否正常、考虑更换故障硬件。

场景 6：僵尸进程堆积

成因： 子进程已经退出，但父进程没有调用 wait() 或 waitpid() 回收子进程资源。僵尸进程不会占用 CPU 和内存，但会占用进程号，数量过多可能导致无法创建新进程。

ps -ef | grep defunct                                  # 找僵尸进程
ps -eo pid,ppid,stat,comm | awk '$3 ~ /Z/ {print $0}'  # 记录父进程 PPID
kill -s SIGCHLD <PPID>   # 给父进程发 SIGCHLD，提示其回收子进程
kill <PPID>              # 父进程本身有 bug 无法回收 → 只能重启父进程（或 kill -9 强杀）

⚠️ 重启父进程前需要确认业务影响。根本措施：修复应用代码，确保正确处理子进程退出。

四、常用命令速查（按场景分类）

# 负载与 CPU
uptime; nproc; lscpu; top; htop; sar -u 1 5
# 内存
free -h; cat /proc/meminfo; swapon -s; vmstat 1 5
# 磁盘 IO
iostat -x 1 5; iotop -o; df -h; df -i; smartctl -a /dev/sda
# 网络
sar -n DEV 1 5; ifstat; nload; netstat -antp; ss -antp; ethtool -l eth0; cat /proc/softirqs
# 进程
ps aux --sort=-%cpu | head -20; ps -eo stat | sort | uniq -c | sort -rn
ps aux | awk '$8 ~ /D/ {print $0}'; ps aux | awk '$8 ~ /Z/ {print $0}'; pstree -p
# 进程行为
lsof -p <PID>; lsof -i -a -p <PID>; strace -p <PID> -c -f; pstack <PID>
cat /proc/<PID>/io; cat /proc/<PID>/stack; cat /proc/<PID>/status; top -H -p <PID>
cat /proc/<PID>/cmdline    # 进程的命令行
cat /proc/<PID>/environ    # 进程的环境变量
# 优先级与内存管理
renice +10 -p <PID>; ionice -c3 -p <PID>
sync && echo 3 > /proc/sys/vm/drop_caches; cat /proc/sys/vm/swappiness
cat /proc/meminfo | grep -i huge   # 查看内存大页
# 系统信息
uname -r; cat /etc/os-release; journalctl -xe; dmesg | tail -50; sar -q 1 5

五、配套配置示例

5.1 swap 与脏页调优（/etc/sysctl.conf）

vm.swappiness = 10             # 降低 swap 使用倾向
vm.dirty_background_ratio = 5  # 增加脏页刷新频率
vm.dirty_ratio = 10

sysctl -p 生效。

5.2 网卡多队列 / RPS / RFS

见第三节场景 4。ethtool -l eth0 输出示例（Channel parameters for eth0：Pre-set maximums Combined: 4，Current hardware settings Combined: 1）确认上限后 ethtool -L eth0 combined 4 设为最大队列数；RPS CPU 掩码 echo f > .../rps_cpus（0xf 表示使用 CPU 0-3）；RFS 全局流表 rps_sock_flow_entries 32768 + 每队列 rps_flow_cnt 2048。

5.3 文件描述符限制

# /etc/security/limits.conf（重新登录生效）
* soft nofile 65536
* hard nofile 65536
* soft nproc 32768
* hard nproc 32768
# /etc/sysctl.conf
fs.file-max = 6553560

5.4 TCP/内核网络参数（/etc/sysctl.conf）

net.core.somaxconn = 32768
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 10000 65000

内核参数全景见 linux-kernel-tuning-production 与 linux-kernel-tuning-guide。

六、日志与监控观察方法

系统日志关键字（journalctl -xe | tail -50 / dmesg | tail -50；持续监控用 journalctl -f）： Out of memory（内存不足）、I/O error（磁盘 IO 错误）、segfault（进程段错误）、hung task（进程卡死）、soft lockup（软锁死）/ hard lockup（硬锁死）。

应用日志常见路径： Nginx /var/log/nginx/error.log、Apache /var/log/httpd/error_log、MySQL /var/log/mysql/error.log、Redis /var/log/redis/redis-server.log、PHP-FPM /var/log/php-fpm/error.log。

Prometheus + Grafana 重点指标： node_load1/node_load5/node_load15（Load Average）、node_cpu_seconds_total（CPU 使用时间）、node_memory_MemAvailable_bytes（可用内存）、node_memory_SwapCached_bytes（Swap 使用量）、node_disk_io_time_seconds_total（磁盘 IO 时间）、node_disk_read_bytes_total（磁盘读字节数）、node_disk_written_bytes_total（磁盘写字节数）、node_network_receive_bytes_total（网络接收字节数）、node_network_transmit_bytes_total（网络发送字节数）。以上指标名称仅供参考，实际指标名称取决于使用的 exporter 版本。

七、五条典型排查路径

• Load 高 + CPU 高：uptime → top 确认 → ps aux --sort=-%cpu 找进程 → lsof -p → strace -p -c → 判断计算密集（优化代码/扩容）还是异常进程（重启/kill）→ 验证
• Load 高 + CPU 空闲：top 看 wa 高 → iostat -x 1 5 确认 IO 瓶颈 → iotop -o 找进程 → lsof 看文件 → 日志写入多调级别/轮转、慢查询优化 SQL/加索引 → 验证
• 多个 D 状态进程：ps aux | awk '$8 ~ /D/' → /proc/<PID>/stack 看堆栈 → 磁盘 IO 查健康、NFS 查网络与服务 → 强制卸载或重启服务 → 无法解决重启系统
• 软中断过高：top 的 si 高 → /proc/softirqs 确认网络软中断 → sar -n DEV 确认流量 → ss/netstat 找进程 → ethtool -l 查队列 → 多队列 + RPS + RFS → 验证 si 下降
• 内存不足频繁 swap：free -h + vmstat 确认 si/so → ps aux --sort=-%mem 找进程 → 优化内存或扩容 → 清缓存临时缓解（慎用）→ 调 swappiness → 验证

八、风险提醒与回滚

五类操作风险：

四类回滚：

# 内核参数：恢复备份或单参数回默认
cp /etc/sysctl.conf.bak /etc/sysctl.conf && sysctl -p
echo 60 > /proc/sys/vm/swappiness          # swappiness 回默认 60
# 网卡：队列回 1、清空 RPS
ethtool -L eth0 combined 1
echo 0 > /sys/class/net/eth0/queues/rx-0/rps_cpus
# 服务/进程：版本回滚、恢复旧配置/数据/快照；kill 错了重新拉起
systemctl start <服务>   # 或 /path/to/binary &

九、生产环境操作纪律

• 操作前检查：确认当前是否业务高峰期、确认是否有重要任务正在执行、确认是否有备份、确认回滚方案是否可行、确认相关人员是否知晓
• 操作中监控：持续观察监控面板/应用日志/系统日志，准备随时回滚
• 操作后验证：验证负载/业务/监控是否恢复正常，记录操作过程和结果
• 权限与变更：生产环境操作需要审批，重要操作需要双人确认，记录操作日志，避免直接使用 root 用户；遵循变更流程，记录变更内容/原因/影响/回滚方案
• 应急预案：准备应急联系人列表、应急处理流程、常用命令清单，定期演练应急流程

十、总结

• 理解核心概念：Load Average 统计 R + D 状态进程数；必须结合核心数判断；Load 高不一定是 CPU 高，可能是 IO 瓶颈
• 建立排查路径：先整体后局部、先观察后操作、先排除明显问题、先非侵入后侵入、记录现场
• 熟练使用工具：uptime/top/htop（负载 CPU）、free/vmstat（内存 swap）、iostat/iotop（磁盘 IO）、sar/netstat/ss（网络）、ps/lsof/strace/pstack（进程）
• 掌握分析方法：四大资源分类排查、关注进程状态分布（重点 R 和 D）、深挖异常进程的系统调用/文件/连接、多指标综合判断
• 采取有效措施：临时措施（降低优先级、清理缓存、限速等）+ 根本措施（优化代码、调整配置、扩容资源）；高风险操作需要评估影响、准备回滚；生产环境操作需要遵循变更流程
• 形成闭环：修复后必须验证效果；准备回滚方案；记录排查过程和结果，形成故障报告和知识沉淀；优化监控告警和预防机制

只有经过大量实战积累，才能在生产环境故障时快速定位问题、采取正确措施、恢复业务正常。本文提供的是系统化的排查思路和工具方法，需要结合具体业务场景和系统特点灵活运用。

关联页面