服务器磁盘IO瓶颈怎么排查：从iostat到定位高IO进程

服务器突然变慢、网站响应卡顿，登录后top看到wa（等待IO的CPU时间）很高，但CPU和内存看起来都正常——这种情况大概率是遇到了磁盘IO瓶颈。

排查的核心思路是：先确认瓶颈确实在磁盘，再找到是哪个进程、哪个文件在大量读写，最后根据原因做优化或限流。
下面按零基础也能照做的顺序展开。

先判断是不是磁盘IO的问题

不要一上来就查磁盘，先用系统自带命令快速确认瓶颈方向。

登录服务器后执行：

top

重点看两行：

• %Cpu(s)那一行里的wa值。wa是CPU等待磁盘IO完成的时间占比，如果持续超过20%，说明磁盘很可能是瓶颈。
• load average如果远高于CPU核数，同时wa也高，进一步印证是IO等待导致。

也可以直接看整体负载：

uptime

如果1分钟、5分钟、15分钟负载都持续偏高，而CPU使用率不高，就要往磁盘方向查。

注意：wa高不绝对等于磁盘慢，也可能是NFS、网络存储等外部IO等待。
先按本地磁盘排查，如果本地磁盘指标正常，再考虑存储网络。

用iostat确认磁盘的繁忙程度

iostat是排查磁盘性能最常用的工具。
如果系统提示command not found，需要先安装：

# CentOS / RHEL
sudo yum install sysstat -y

# Ubuntu / Debian
sudo apt install sysstat -y

安装后执行：

iostat -x 1 5

参数含义：-x显示扩展统计信息，1表示每秒刷新一次，5表示共输出5次。

重点看这几列：

• %util：设备繁忙百分比。持续接近100%说明磁盘几乎一直在处理IO请求，已经饱和。
• await：每个IO请求的平均等待时间（毫秒）。机械硬盘通常个位数到十几毫秒，如果持续超过50ms甚至上百，说明响应很慢。
• r/s和w/s：每秒读写次数。结合await判断是请求太多还是单次太慢。
• rkB/s和wkB/s：每秒读写数据量，用来判断吞吐量是否异常。

判断逻辑：如果%util高且await高，说明磁盘扛不住了；
如果%util不高但await高，可能是单次IO太大或存储链路有问题。

找到是谁在大量读写

确认磁盘繁忙后，下一步是定位具体进程。

方法一：用iotop按进程排序

iotop能直接显示每个进程的磁盘读写量。
安装：

# CentOS / RHEL
sudo yum install iotop -y

# Ubuntu / Debian
sudo apt install iotop -y

运行：

sudo iotop -o -d 2

-o只显示有IO活动的进程，-d 2表示每2秒刷新。
输出里DISK READ和DISK WRITE两列能直接看出哪个进程在读写在大量数据。

如果iotop不可用，可以用pidstat：

pidstat -d 1 5

它会按进程列出每秒读写KB数，同样能定位到高IO进程。

方法二：用lsof查看进程打开的大文件

找到可疑进程PID后，可以看它打开了哪些文件：

lsof -p  | grep -E 'REG|DIR'

如果发现它在反复读写某个日志文件或数据文件，就能进一步判断原因。

常见原因和对应处理方向

定位到高IO进程后，常见的几类原因和处理思路：

• 日志写入过猛：比如应用把调试日志开到了全量级别，或者某个服务在疯狂写错误日志。处理方式是调整日志级别、增加日志轮转（logrotate）、或临时清空过大的日志文件。
• 数据库慢查询或全表扫描：MySQL、PostgreSQL等数据库如果缺少索引，会频繁读磁盘。可以用SHOW PROCESSLIST或慢查询日志确认，再优化SQL或加索引。
• 备份或同步任务：定时备份、rsync、文件同步工具在运行时会占用大量IO。可以调整任务执行时间，避开业务高峰，或用ionice降低其IO优先级。
• 磁盘本身性能不足：机械硬盘随机读写能力弱，如果业务是大量小文件随机读写，考虑换SSD或调整存储架构。
• 内存不足导致频繁换页：free -h看到swap使用量持续增长，说明内存不够，系统在反复读写交换分区。这种情况需要加内存或优化应用内存占用。

避坑提醒：不要一看到IO高就盲目重启服务或删文件。
先确认是哪个进程、在读什么文件，否则重启后问题可能很快复现。
删除文件前也要确认不是正在使用的数据文件。

验证优化是否生效

调整后不要只看一次结果就下结论。
建议在业务高峰期或问题复现时段，重新执行：

iostat -x 1 10

观察%util和await是否回落到正常范围。
同时用top确认wa是否下降，用iotop -o确认没有单个进程持续大量读写。

如果优化后指标仍然异常，可以进一步用iostat -x对比不同磁盘（比如系统盘和数据盘）的表现，确认瓶颈是否集中在某一块盘上。

几个容易踩的坑

• 只看CPU不看IO等待：wa高但CPU空闲时，很多人会误以为服务器很闲，实际磁盘已经满负荷。
• 忽略swap的影响：内存不足时，swap读写会表现为磁盘IO高，但根源在内存。用free -h和vmstat 1确认si、so是否非零。
• 在高峰期做全量备份：备份任务本身就会产生大量顺序读写，如果和业务高峰重叠，很容易把磁盘打满。
• 用机械硬盘跑高并发小文件业务：这种场景对随机IO要求高，机械硬盘很难满足，优化空间有限，需要考虑硬件升级。

排查磁盘IO瓶颈没有一招搞定的命令，关键是按“确认瓶颈→定位进程→分析原因→验证效果”的顺序走。
先把iostat和iotop用熟，大部分问题都能找到方向。