服务器卡顿、负载飙升?Linux磁盘IO过高排查实操指南(iostat+iotop)

做运维、后端开发的小伙伴，大概率都遇到过这种场景：

服务器CPU负载不高、内存充足，但系统响应极慢、接口超时、SSH卡顿、top查看iowait居高不下。

90%的情况，都是磁盘IO瓶颈在作祟！

磁盘IO过高是Linux服务器最常见的性能问题之一，业务读写、日志刷屏、定时任务、数据库刷盘等，都可能瞬间打满磁盘IO，拖垮整个服务。

很多人排查IO问题只会盲目敲命令，看不懂指标、找不准根源。今天就给大家分享一套极简、落地、可直接复用的排查流程：iostat定位磁盘瓶颈 + iotop锁定异常进程，从判断问题、分析指标、精准定位到问题解决，一次性讲透！

一、先搞懂：IO过高为什么会导致服务器卡顿？

简单来说：CPU执行读写请求时，需要等待磁盘完成操作，这段等待时间就是iowait。

当磁盘读写压力过大、处理不过来时，大量CPU时间都会浪费在等待磁盘上，即便CPU、内存空闲，业务进程也会被阻塞，最终表现为：

• 系统负载异常升高

• 业务接口响应超时、卡顿

• 日志输出缓慢、文件读写延迟

• 数据库查询、写入性能暴跌

核心排查逻辑（牢记这两步）

✅ 第一步：iostat —— 查「哪块磁盘」满了、IO负载多少、是否瓶颈

✅第二步：iotop —— 查「哪个进程」在疯狂读写磁盘，定位元凶

二、iostat 实操：判断磁盘是否存在IO瓶颈

iostat 是Linux自带的磁盘IO统计工具，属于sysstat工具集，绝大多数服务器默认预装，未安装可直接执行对应命令安装。

1、工具安装（全网通用）

# CentOS / RHEL / Alibaba Cloud Linux

yum install -y sysstat

# Ubuntu / Debian

apt install -y sysstat

2、核心实操命令（运维高频必用）

日常排查直接用这条终极命令，简洁、精准、无冗余：

iostat -dxz 1

参数详解：

• -d：只展示磁盘IO统计，屏蔽CPU无关信息

• -x：展示详细扩展IO指标（排查瓶颈必备）

• -z：隐藏无IO负载的空闲磁盘，只看有压力的设备

• 1：每秒刷新一次数据，实时监控

3、关键指标解读（看懂这4个就够了）

很多人排查无效，核心是看不懂指标！重点关注以下4个核心字段，快速判断瓶颈：

① %util（核心判定指标）

磁盘设备繁忙时间占比，判断磁盘是否打满的黄金指标。

• %util 持续 ≥80%：磁盘IO压力极大，存在性能瓶颈

• %util 持续 ≥95%：磁盘基本饱和，读写阻塞严重

• 机械硬盘(HDD)：%util 100% 基本判定IO打满

• 固态硬盘(SSD)：多并发场景下100%不一定瓶颈，需结合其他指标

② r/s、w/s

每秒磁盘读、写请求次数，可快速区分是读瓶颈还是写瓶颈。

③ rkB/s、wkB/s

每秒读写数据量，直观查看磁盘吞吐大小。如需MB单位，可将命令改为 iostat -dxzm 1。

④ await、svctm

• await：IO请求平均等待时间（毫秒），数值越大，读写延迟越高，业务越卡

• svctm：IO请求平均处理时间

核心判断公式：await 远大于 svctm → 磁盘队列拥堵，IO严重过载

4、典型异常场景

执行命令后，若出现：%util 99%、w/s 极高、await 几十毫秒，基本可以确定：当前磁盘写入请求爆满，导致系统阻塞。

三、iotop 实操：精准定位搞事进程

iostat 只能告诉我们「磁盘忙」，但不知道「谁让磁盘忙」。想要精准溯源，必须用 iotop 实时监控进程IO占用情况，一键锁定元凶。

1、工具安装

# CentOS
yum install -y iotop
# Ubuntu
apt install -y iotop

2、极简排查命令（生产首选）

iotop -od 2

参数详解：

• -o / --only：只显示有IO读写活动的进程，过滤所有空闲进程，界面清爽不杂乱

• -d 2：每2秒刷新一次数据，避免刷新过快错过异常

3、核心字段解读

重点看这3列，快速定位问题：

• DISK WRITE：进程每秒磁盘写入量（高频异常点）

• DISK READ：进程每秒磁盘读取量

• IO>：进程IO占用百分比，数值越高越可疑

4、实战定位场景

执行命令后，大概率会看到这些高频异常进程：

• java / python / php：业务代码疯狂打日志、批量写入文件

• mysqld：数据库大批量写入、慢查询刷盘、日志归档

• rsync / cp / tar：文件同步、备份、压缩任务占用大量IO

• logrotate：日志切割瞬间引发IO峰值

找到PID后，可通过 ps -ef | grep PID 查看进程详情，确认业务来源。

四、完整排查流程（直接照搬工作用）

遇到服务器卡顿、iowait高时，严格按照以下步骤排查，零遗漏、高效率：

步骤1：确认是否为IO问题

执行 top 命令，观察 CPU 栏 %iowait

• iowait 持续 >20%：基本确定磁盘IO瓶颈

• iowait 极低：排除IO问题，排查CPU、网络、内存

步骤2：iostat 定位异常磁盘

iostat -dxz 1

查看哪块磁盘%util满载，区分是读瓶颈还是写瓶颈

步骤3：iotop 锁定异常进程

iotop -od 2

找出高读写进程，记录PID和进程名称

步骤4：溯源解决问题

• 业务日志刷屏：调整日志级别、关闭冗余日志、增加日志缓冲

• 数据库IO高：优化慢查询、调整刷盘策略、分库分表

• 定时备份/压缩：错开业务高峰、限速执行任务

• 异常进程：临时kill止损，排查代码漏洞、循环读写问题

五、高频误区避坑

1、误区：%util=100% 一定是磁盘坏了

错！机械硬盘单队列请求极易打满%util，多为业务读写过载，并非硬件故障；SSD并发能力强，100%util大概率无瓶颈，需结合await判断。

2、误区：只看吞吐，不看IO次数

很多时候吞吐不高，但IO请求次数极多、单次IO极小（频繁小文件读写），也会打满磁盘，这是最容易被忽略的点。

3、误区：直接kill进程解决问题

kill进程只能临时止损，必须溯源：代码BUG、日志策略、定时任务、数据库问题，否则问题会反复复现。

六、日常预防优化建议

• 规范日志输出，禁止线上服务疯狂打印DEBUG日志

• 大文件拷贝、备份、同步任务，避开业务高峰期

• 数据库定期优化慢查询，调整innodb刷盘参数

• 小文件过多场景，定期归档清理，减少频繁读写

• 核心业务优先使用SSD，规避机械硬盘IO性能短板

结尾总结

Linux磁盘IO排查，核心就是iostat看磁盘、iotop看进程的组合打法，没有复杂原理，重在熟练使用、看懂指标。

记住核心口诀：iowait高看util，util高查读写，读写高找进程，绝大多数IO卡顿问题都可以快速解决。

建议大家收藏本文，下次遇到服务器IO异常，直接对照排查，高效解决问题，告别盲目排查！

❤️ 觉得有用，欢迎点赞、转发，关注我，持续分享运维干货、服务器排查实战技巧！