排查系统缓慢

Linux 系统缓慢排查：从负载分析到根源定位

当 Linux 系统出现卡顿、响应缓慢时，需要系统性地排查资源瓶颈（CPU、内存、IO 等）。本文基于 “先定位瓶颈类型，再深挖具体原因” 的思路，详细介绍排查步骤和工具，帮助快速定位系统缓慢的根源。

第一步：通过 uptime 判断系统负载

uptime 是排查系统缓慢的起点，它能快速反映系统的整体负载情况：

uptime
# 输出示例：14:22:15 up 226 days, 15:08,  2 users,  load average: 0.38, 0.19, 0.15

关键指标：平均负载（load average）

• 三个数值分别代表1 分钟、5 分钟、15 分钟内的系统平均负载，表示单位时间内等待 CPU 处理的任务数（包括运行中、就绪和不可中断睡眠的进程）。
• 判断标准：
  • 若负载值 ≤ CPU 核心数：系统负载正常（如 4 核 CPU 负载 ≤ 4 属正常）。
  • 若负载值 > CPU 核心数且持续升高：系统可能存在资源瓶颈。
  • 对比三个值可判断负载趋势：1 分钟 > 5 分钟 > 15 分钟 → 负载正在升高；反之则降低。

第二步：确定瓶颈类型（CPU / 内存 / IO）

系统缓慢的核心原因通常是 CPU、内存或 IO 中的某一项资源饱和。需结合工具进一步分析：

检查 CPU 瓶颈：top 或 mpstat

用 top 观察 CPU 使用率：

top  # 进入实时监控界面，按 P 按 CPU 使用率排序

关注指标：

• %CPU 列：单个进程的 CPU 占用率（若某进程长期 ≥ 90%，可能是元凶）。
• 顶部%Cpu行：
  • us（用户态 CPU）：若长期 ≥ 80%，可能是应用程序（如 Java、Python）消耗过多 CPU。
  • sy（系统态 CPU）：若长期 ≥ 30%，可能是内核操作（如频繁系统调用、进程调度）异常。
  • wa（IO 等待 CPU）：若长期 ≥ 20%，说明 CPU 因等待磁盘 IO 而空闲，需重点排查 IO 问题。
  • id（空闲 CPU）：若长期 ≤ 10%，说明 CPU 资源紧张。

用 mpstat 分析多核心负载：

mpstat -P ALL 5  # 每 5 秒输出一次所有 CPU 核心的使用率

• 若某一核心 %idle 接近 0，而其他核心空闲，可能是应用程序未充分利用多核（单线程瓶颈）。

检查内存瓶颈：free 或 top

内存不足（或内存泄漏）会导致频繁的 Swap 交换，引发系统卡顿。

用 free 查看内存使用：

free -h  # -h 以人性化单位显示
# 输出示例：
#              total        used        free      shared  buff/cache   available
# Mem:           31G         15G        5.2G        2.1G         11G         13G
# Swap:          15G        2.3G         13G

关键指标：

• available：实际可用内存（比 free 更准确，包含可回收的缓存）。
• 若 available 长期 ≤ 总内存的 10%，且 Swap: used 持续增长，说明内存不足，系统正在频繁使用 Swap（磁盘模拟内存，速度慢）。

用 top 定位内存消耗进程：

在 top 界面按 M 按内存使用率排序，关注 %MEM 列，若某进程 %MEM 过高且持续增长，可能存在内存泄漏。

检查 IO 瓶颈：iostat 或 iotop

IO 瓶颈（磁盘读写慢）会导致进程因等待数据而阻塞，表现为 top 中 %wa 升高。

用 iostat 分析磁盘 IO：

iostat -x 5  # -x 显示详细信息，每 5 秒刷新一次

关键指标：

• %util：磁盘使用率（若 ≥ 80%，说明磁盘繁忙）。
• await：IO 请求平均等待时间（正常应 <10ms，若> 50ms 说明 IO 响应慢）。
• r/s/w/s：每秒读写请求数；rkB/s/wkB/s：每秒读写数据量（判断是随机 IO 还是大文件读写）。
• 结合 Device 列可定位具体繁忙的磁盘（如 /dev/sda）。

用 iotop 定位 IO 消耗进程：

iotop  # 类似 top，但按 IO 使用率排序（需安装，如 yum install iotop）

• 关注 DISK READ/DISK WRITE 列，找出频繁读写的进程。

第三步：追溯历史数据（sar 命令）

若问题已消失（非实时发生），需通过 sar 查看历史监控数据（前提是系统已安装 sysstat 工具并启用日志）。

sar 常用用法：

# 查看当天的 CPU 统计（默认保存 /var/log/sa/ 目录）
sar

# 查看当天的内存使用
sar -r

# 查看当天的磁盘 IO 统计
sar -b  # 或 sar -d 更详细

# 查看指定时间段的记录（-s 开始时间，-e 结束时间）
sar -s 18:00:00 -e 18:30:00  # 查看 18:00-18:30 的数据

关键指标对应：

• CPU 瓶颈：sar 中 %user（用户态）、%system（系统态）、%iowait（IO 等待）与 top 一致。
• 内存瓶颈：sar -r 中 memfree（空闲内存）、swapused（Swap 使用率）。
• IO 瓶颈：sar -b 中 tps（每秒 IO 次数）、bread/s（读速率）、bwrtn/s（写速率）。

常见场景与解决方案

1. CPU 使用率高（%us 或 %sy 高）

• 原因：应用程序逻辑低效（如死循环）、频繁系统调用（如大量 fork）、中断风暴。
• 解决：
  • 用 top 定位高 CPU 进程，分析其代码或配置（如 Java 程序可通过 jstack 查看线程栈）。
  • 若 %sy 高，检查是否有频繁的文件操作、网络连接或进程创建销毁。

2. 内存不足（available 低 + Swap 高）

• 原因：应用内存泄漏、程序配置的内存上限过高（如 JVM -Xmx 设置过大）。
• 解决：
  • 用 top 或 pmap 定位内存消耗大的进程，重启或优化（如调整 JVM 参数）。
  • 若频繁使用 Swap，可临时增加 Swap 空间，或长期升级物理内存。

3. IO 瓶颈（%util 高 + await 高）

• 原因：大量随机读写（如数据库索引失效）、磁盘性能不足（如机械盘跑大数据量）、文件系统错误。
• 解决：
  • 用 iotop 定位 IO 密集型进程，优化其读写逻辑（如批量写入、使用缓存）。
  • 检查磁盘健康状态（smartctl -a /dev/sda），排除硬件故障。
  • 升级至 SSD 或调整 RAID 级别提升 IO 性能。