Linux 服务器磁盘 I/O 很高怎么排查？从 iowait 到进程读写定位-速维云

先判断是不是“磁盘真的慢”

很多网站故障看起来像数据库卡、PHP 卡、后台卡，最后追到服务器上才发现，真正拖慢请求的是磁盘读写。典型表现包括：页面偶尔打开很慢、接口响应忽快忽慢、数据库查询突然堆积、备份或日志压缩时整站变慢、CPU 使用率不高但负载一直下不来。

排查这类问题时，不建议一开始就盯着某个进程重启。更稳妥的顺序是先确认系统是否存在明显的 I/O 等待，再看磁盘吞吐、延迟和队列，最后定位到具体进程与文件。这样可以避免把“磁盘等待”误判成“程序本身写得慢”。

一个很常见的误区是只看磁盘容量。容量没满，只能说明还能写入文件；它不能说明磁盘响应足够快。云服务器、本地硬盘、数据库盘、日志盘都可能在容量正常的情况下出现 I/O 抖动。

用 top 和 uptime 看负载与 iowait

第一步可以先执行 uptime 或 top，观察 load average 是否明显高于 CPU 核心数。如果一台 2 核服务器长期 load 到 8、10，但 CPU 的 user 和 system 占比并不高，就要怀疑进程正在等待磁盘、网络或锁资源。

在 top 里重点看 %wa，也就是 iowait。它表示 CPU 空着却在等 I/O 完成的时间比例。短时间升高不一定有问题，例如备份、解压、批量导入时会出现波动；如果持续偏高，并且网站响应也变慢，就需要继续查磁盘层。

需要注意，iowait 不是“磁盘坏了”的直接证据。它只说明系统里有任务在等待 I/O。等待的原因可能是磁盘性能不足，也可能是数据库刷盘太频繁、日志写入过多、备份任务和业务高峰撞在一起，或者云服务器所在宿主环境出现抖动。

磁盘 I/O 排查要把系统指标、进程行为和业务时间点放在一起看。

用 iostat 看吞吐、延迟和队列

如果系统已安装 sysstat，可以使用 iostat -xz 1 连续观察磁盘指标。这里不要只看读写速度，还要看 await、util、aqu-sz 这类能反映等待和队列情况的指标。

await 可以粗略理解为一次 I/O 请求平均等待和处理所花的时间。它持续升高时，说明请求完成变慢。util 表示设备繁忙程度，长期接近 100% 时，通常说明这个盘已经很忙。aqu-sz 则反映平均队列长度，队列越长，说明请求越容易排队。

但这些指标不能机械套阈值。不同磁盘、不同云盘类型、不同数据库负载的正常范围并不一样。更实用的判断方法是对比“故障时”和“正常时”的差异：如果平时 await 很低，出问题时突然升高，同时网站响应变慢，这个方向就值得继续深挖。

用 pidstat 和iotop定位进程

确认磁盘层存在异常后，下一步要找是谁在读写。可以使用 pidstat -d 1 查看各进程的读写速率，也可以用 iotop 观察实时 I/O 消耗。没有安装这些工具时，也可以先从 ps、应用日志、定时任务记录和数据库状态入手。

常见的高 I/O 来源包括 MySQL 大查询、慢日志或 binlog 增长、网站访问日志暴涨、备份脚本压缩文件、图片处理任务、搜索索引重建、Docker 容器日志失控等。对 WordPress、论坛、商城这类站点来说，插件生成缓存、批量缩略图、爬虫访问导致日志暴涨，也经常会把磁盘拖慢。

定位进程后，不要急着 kill。先判断它是不是关键业务进程。如果是备份、压缩、同步之类的后台任务，可以考虑暂停或错峰；如果是数据库或 Web 服务本身，就要继续分析具体 SQL、日志量、缓存命中率和访问来源。

把时间点和业务动作对起来

磁盘 I/O 问题往往不是全天持续，而是集中在某些时间点出现。排查时可以把慢的时间段和业务动作对齐：是否刚好在凌晨备份、是否有定时采集、是否有安全扫描、是否有人批量上传图片、是否 CDN 回源突然增多、是否爬虫访问集中爆发。

这一步很重要，因为它能把“服务器性能不够”的笼统判断拆成可处理的问题。例如备份导致慢，可以调整备份时间、降低压缩优先级或改成增量备份；日志导致慢，可以做日志轮转与采样；数据库刷盘压力大，可以优化索引、慢查询和缓存策略。

如果业务已经进入稳定增长阶段，单纯靠重启服务并不能解决 I/O 压力。可以考虑把数据库、对象存储、缓存、静态资源分层处理。选择云服务器时，也要关注磁盘类型、IOPS、带宽和业务位置，而不只是 CPU 与内存。像速维云云服务器这类方案，在部署网站、数据库或运维测试环境时，就需要结合实际读写压力选择合适配置，避免只按最低规格上线。