Linux 磁盘 IO 飙高怎么办：从 iostat 到 pidstat 一步步定位

Linux 服务器突然变慢时，很多人第一反应会看 CPU 和内存。但有一类问题更隐蔽：CPU 不算高，内存也够，接口却越来越慢，登录服务器后连简单命令都反应迟缓。这时磁盘 IO 很可能已经顶满。

这篇文章按一次真实排查思路来走：先从接口变慢的现象入手，用 iostat 判断磁盘是否繁忙，再用 pidstat 找到持续写盘的进程，最后通过限速清理、迁移写入目录和复查指标确认恢复。

摘要

Linux 磁盘 IO 飙高时，不要只看磁盘剩余空间。先用 iostat -xz 1 3 看 %util、await 和队列指标，再用 pidstat -d 1 5 找出正在大量读写的进程。定位到目录后，再决定是限速清理、压缩归档、迁移写入路径，还是调整应用日志策略。

适合人群

• 负责 Linux Web 服务、任务服务、日志服务的开发和运维人员。
• 遇到接口变慢、任务堆积、磁盘灯持续闪烁但 CPU 不高的读者。
• 想把磁盘 IO 排查流程整理成固定检查清单的团队成员。

问题现场：接口变慢但 CPU 不高

我们先看现象。业务方反馈报表接口从 200ms 变成 10 秒以上，部分请求还出现超时。登录服务器后先看负载，发现 load average 偏高，但 CPU 使用率并没有明显打满。

uptime
top

这时不要急着判断是代码慢。load 偏高但 CPU 不高，常见原因之一就是进程在等待磁盘读写。应用日志、临时文件、报表导出、备份任务、批量压缩都可能让磁盘处于高等待状态。

这一步说明，我们需要把排查方向从 CPU 切到磁盘。接下来先确认磁盘是否真的繁忙，再找是谁在持续读写。

第一步观察：用 iostat 判断磁盘是否顶满

第一条线索来自 iostat。它可以看到每块磁盘的利用率、等待时间和队列情况。排查时不要只看一次瞬时结果，建议连续采样几次。

iostat -xz 1 3

重点看这几个指标：

如果 %util 持续很高，await 也明显升高，就可以基本确认接口慢和磁盘等待有关。现在的问题变成：是哪一个进程在制造这些 IO？

第二步验证：用 pidstat 找写盘进程

接着验证进程维度。pidstat 可以按进程展示磁盘读写情况，适合从系统指标追到具体程序。

pidstat -d 1 5

输出里重点看进程名、PID、每秒读写量。假设看到某个日志处理进程或报表进程写入量长期很高，就继续往下查它打开了哪些文件。

lsof -p 12345

如果 lsof 里大量文件集中在 /var/log/app、/data/export 或某个临时目录，那么定位范围就缩小了。到这里不要立刻删文件，先确认文件增长速度和业务用途。

第三步定位：确认写入目录和文件增长

现在可以定位到目录层面。我们要看两件事：哪些目录最大，哪些文件还在持续增长。

du -sh /var/log/* | sort -h | tail -20
find /var/log/app -type f -size +500M -print
ls -lh /var/log/app

如果某个日志文件持续增长，可以间隔几秒看两次大小变化。增长特别快时，通常有三类原因：日志级别过细、异常重复打印、临时任务把结果不断写入本地磁盘。

wc -l /var/log/app/app.log
tail -100 /var/log/app/app.log

这一步要回答一个问题：这是正常的大量写入，还是异常循环写入？如果是正常清理任务导致 IO 高，要限速；如果是应用异常疯狂写日志，要先降日志量或修复异常入口。

修复方案：限速清理、迁移写入和复查指标

修复时不要做“一刀切”动作。磁盘 IO 已经很高时，暴力压缩、批量删除、整目录搬迁都可能让磁盘更忙。更稳的方式是先控制速度，再迁移写入路径，最后复查指标。

1. 对清理和归档做限速

如果是历史文件归档，优先使用带速率限制的同步或分批处理，避免一次性把磁盘打满。

rsync --bwlimit=2048 -av /var/log/app/ /data/archive/app-log/
ionice -c2 -n7 -p 12345

--bwlimit 可以限制传输速度，ionice 可以调整已有进程的 IO 优先级。实际执行前要确认进程是否允许调整，以及业务是否接受较慢的归档速度。

2. 迁移高频写入目录

如果应用把大量临时文件写到系统盘，可以把临时目录迁移到更合适的数据盘，并在应用配置里修改写入路径。迁移前要先停掉相关写入任务或让应用切换到维护窗口，避免文件一边写一边搬。

mkdir -p /data/app-tmp
cp -a /var/app/tmp/. /data/app-tmp/
mv /var/app/tmp /var/app/tmp.bak
ln -s /data/app-tmp /var/app/tmp

如果项目支持直接配置临时目录，更推荐改配置而不是依赖软链接。软链接适合过渡，长期方案还是让应用明确写入数据盘。

3. 复查关键指标

修复后不要只看接口恢复，还要回到磁盘指标确认。至少复查三项：%util 是否下降，await 是否恢复，接口耗时是否回到正常范围。

iostat -xz 1 5
pidstat -d 1 5

如果 %util 从 90% 以上降到 20% 以下，接口耗时也回落，说明这次处理有效。如果指标仍然很高，就继续追读写进程，不要只盯着刚才那个目录。

常见误区

1. 只看磁盘空间，不看磁盘等待

磁盘还剩很多空间，不代表 IO 没问题。接口慢和任务卡住经常是等待时间变长，而不是空间不足。

2. 发现大文件就立刻删除

正在被进程打开的文件即使删除，空间也可能不会马上释放，而且删除本身也可能带来额外 IO。先确认文件是否仍被打开，再决定清理策略。

3. 在高峰期跑大批量归档

归档任务看起来是维护动作，但它同样会读写磁盘。最好安排在低峰，并加上速度限制。

4. 忽略应用日志级别

异常重复打印会快速放大 IO。排查时要看日志内容，不要只看文件大小。大量相同错误反复出现时，真正要处理的是异常源头。

总结检查清单

• 接口变慢但 CPU 不高时，先考虑 IO 等待。
• 用 iostat -xz 1 3 看 %util、await 和队列。
• 用 pidstat -d 1 5 找持续读写的进程。
• 用 lsof -p PID 和目录大小确认写入位置。
• 清理和迁移要限速，避免修复动作继续打满磁盘。
• 修复后复查 iostat、接口耗时和日志增长速度。

回到最开始的问题：Linux 磁盘 IO 飙高不是靠猜出来的，要按“系统指标、进程指标、目录文件、修复复查”这条线走。这样既能快速找到写盘源头，也能避免清理动作本身带来新的抖动。