服务器系统负载过高和磁盘IO爆满分析以及解决

1. 事件简述

有一台服务器，发现长时间系统负载很高，且系统负载没能降下来，使用top进行查看

top - 14:46:15 up 481 days, 18:18, 1 user, load average: 61.45, 58.41, 45.99

查看这台服务器进程，该台服务器搭建了oracle，发现有较多运行进程是数据库的，因是测试数据库，所以重启数据库打算释放运行进程，但重启过程中，发现数据库启不起来，处于unhealthy状态，且反应很慢，遂查看磁盘IO使用情况，使用iostat -x 2进行查看：

发现磁盘sdb以及逻辑卷dm-2磁盘I/O利用率已经100%，已经爆满。

2. 问题分析

从截图可以看到关键性能指标如下：

2.1 CPU总体状态（avg-cpu）

说明：CPU 并不是瓶颈，但几乎一半的 CPU 时间都在等待磁盘 I/O。

2.2 磁盘I/O性能

从设备行可以看到：

可以看出：

• sdb与dm-2（逻辑卷）磁盘I/O已100%利用率；
• await在40~50ms，属于非常高的延迟；
• 系统load average超高（61+），主要由I/O阻塞县城导致。

2.3 系统负载（top）

load average: 61.45, 58.41, 45.99

系统负载远高于 CPU 核心数，说明：

• 大量进程在等待I/O；
• 并非CPU计算问题，而是磁盘瓶颈导致任务排队。

2.4 分析总结

单块磁盘（sdb）和逻辑卷（dm-2）被过度使用

• 可能是数据库、日志或缓存目录集中在同一磁盘；
• 或NFS、虚拟机镜像等I/O密集型任务过载。

I/O调度延迟高

• await接近50ms，说明I/O队列严重积压；
• avgpu-sz≈12，表示平均队列长度过长。

可能的文件系统碎片或不合理挂载

• 如果是ext4/xfs长时间运行未优化，碎片和日志写入可能造成延迟。

底层资源池资源紧张

• 因该台服务器是虚拟机，具体资源来源于底层资源池，有可能底层资源池被其他虚拟机过度使用，挤占了该台服务器的资源。

3. 解决问题

根据以上分析，进行逐一排查，最终找到问题根源：底层资源池I/O被某台虚拟机占用了75%以上，导致底层I/O在分配给其他虚拟机时不够用了，通过释放某台虚拟机正在使用的服务资源，从而释放出占用的I/O，磁盘I/O释放出来后，该台服务器恢复正常，如下：

4. 参数含义

4.1 iostat输出

4.1.1 avg-cpu该行输出含义

这是系统性能监控中最重要的一行之一，如截图中部分：

avg-cpu:  %user  %nice  %system  %iowait  %steal  %idle
           1.64   0.00     0.75     46.92    0.00   50.69

这一行通常来自 iostat（或 sar -u）输出，显示的是 CPU 各种使用状态的平均分布。

字段含义总览

原理说明（CPU状态来源）

系统内核统计每个CPU在不同状态下的累计时间，主要有：

• user：用户代码执行；
• system：内核代码执行；
• iowait：CPU空闲但有I/O等待；
• idle：CPU真正空闲；
• nice：带优先级调整的用户任务；
• steal：虚拟化被抢占的CPU时间。

iostat 或 sar 会在一段时间采样后输出每种状态的占比。

截图中的实际数值分析

关键指标解释重点

1） %user + %system

代表 CPU 真正“干活”的时间比例（执行应用 + 内核）。

• 正常服务器负载：10% ~ 70%；
• 如果接近 100%，CPU是瓶颈；
• 这里只有 2.39%，CPU 很闲。

2） %iowait

表示CPU空闲但被I/O阻塞。

• 正常：0~5%；
• 中等：5~15%；
• 超高：>20%（严重I/O瓶颈）；
• 这里是 46.92% → 极高！

说明：

CPU大部分时间在等磁盘响应（例如数据库读写、日志写入、NFS、虚拟磁盘延迟等）。

3）%idle

CPU真正空闲的比例。

• 如果 %idle 很低 (<10%) 且 %user/%system 高 → CPU计算压力大；
• 如果 %idle 高但 %iowait 也高 → CPU本身闲着，但被I/O拖慢；
• 这里情况：idle 50.69% + iowait 46.92% 典型的 I/O瓶颈导致CPU空等。

4） %steal

如果是虚拟机上运行（如 KVM、VMware），该值 >0 表示宿主机CPU资源被其他虚机抢占。

• 实机通常为 0；
• 若 >10%，说明虚拟化层竞争严重；
• 这里是 0 → 无虚拟化问题。

如何快速判断瓶颈类型

命令补充

# 1. 实时查看CPU各状态分布
mpstat 1

# 2. 查看具体进程的I/O等待情况
pidstat -d 1

# 3. 查看谁导致高 iowait
iotop -aoP

4.1.2 Device该行输出含义

Device 这一行是 iostat -x 命令（或类似工具如 sar -d）输出的核心部分，用来展示各个磁盘或逻辑卷的详细 I/O 性能指标

Device:    rrqm/s wrqm/s  r/s  w/s   rkB/s  wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util

字段详解

举例说明

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 6.00 0.00 49 14 2208 80.00 72.63 11.95 49.76 48.59 53.86 15.87 100.00

分析：

关键指标判断

辅助理解关系图

小结

4.2 top输出

top 命令的第一行（系统总体状态）是系统性能分析中最核心的一行 ：

top - 14:46:15 up 481 days, 18:18,  1 user,  load average: 61.45, 58.41, 45.99

格式说明

top第一行的典型格式为：

top - <时间> up <运行时长>, <登录用户数> users, load average: <1分钟>, <5分钟>, <15分钟>

字段详解

重点：load average含义详解

这是最关键的部分之一。

1）含义

load average 表示 处于“可运行”或“不可中断（D状态）”状态的进程平均数。 简单来说：

• 它反映了系统任务队列的拥堵程度；
• 包括正在运行的任务 + 正在等待 CPU 或 I/O 的任务。

⚠️ 注意：它不是 CPU 使用率，而是“排队长度”。

2）判断标准（与CPU核心数相关）

因此要结合CPU核心数进行分析。

3）该截图上情况：

load average: 61.45, 58.41, 45.99

这表示：

• 过去1分钟平均有 61.45个任务 同时在运行或等待；
• 过去5分钟约58；
• 过去15分钟约46。

结论：系统长时间处于严重过载状态 — 即大量任务在等待资源（CPU或I/O）。 结合前面发的 iostat 截图：

%iowait 高达 46.9%，磁盘 sdb 利用率 100%。

所以此时的高 load average 是由 磁盘 I/O 堵塞 引起的，而非 CPU 饱和。

整体解释总结

延伸分析：load高的原因分类