Linux 云服务器运行网站、数据库、Docker 或其他业务时，有时会出现服务器响应明显变慢，但 CPU 使用率并不高的情况。
例如：
SSH 操作卡顿；
网站打开很慢；
数据库查询延迟增加；
Docker 容器响应变慢；
Load Average 持续升高；
程序大量等待磁盘读写。
这种情况下，问题可能不是 CPU，而是：
磁盘 I/O 压力过高。
磁盘 I/O 指服务器对磁盘进行读取和写入的操作。
如果磁盘长期处于高负载状态，大量程序就会等待磁盘完成读写，从而导致整台服务器出现卡顿。
一、先确认是不是磁盘 I/O 问题
首先执行：
top重点观察：
wa
也就是 I/O Wait。
例如：
%Cpu(s): 8.0 us, 4.0 sy, 0.0 ni, 32.0 id, 55.0 wa如果 wa 长时间明显偏高，说明 CPU 有较多时间正在等待 I/O 完成。
不过单独看 wa 还不能完全判断磁盘状态。
建议继续使用：
iostat -xz 1进行检查。
二、使用 iostat 查看磁盘 I/O
如果系统已经安装 sysstat，可以执行：
iostat -xz 1该命令会持续显示磁盘读写情况。
常见输出中可以重点关注：
r/s
w/s
rkB/s
wkB/s
await
aqu-sz
%util
例如：
Device r/s w/s await aqu-sz %util
vda 52 118 84.6 6.21 98.7如果某块磁盘长期出现较高的 await，并且 %util 也持续很高，就说明该设备当前比较繁忙。
需要注意，单个瞬时数据并不能代表服务器长期存在异常。
建议持续观察一段时间，并结合业务运行情况判断。
三、await 是什么意思？
await 表示 I/O 请求从提交到完成的平均等待时间，通常以毫秒计算。
例如：
await 84.6表示这一段时间内磁盘 I/O 请求平均需要等待较长时间。
如果业务平时只有几毫秒，突然长期增加到几十甚至几百毫秒，就需要继续排查。
但不同存储类型性能差异很大。
例如：
机械硬盘；
SATA SSD；
NVMe SSD；
云盘；
共享存储
不能简单使用同一个数值判断是否异常。
更有意义的是和服务器平时正常状态进行对比。
四、%util 接近 100% 是不是磁盘一定满负载？
%util 可以用于观察磁盘繁忙程度。
例如：
%util 98.7说明设备大部分时间都有 I/O 请求正在处理。
如果传统单队列磁盘长期接近 100%，通常值得重点关注。
不过在现代 NVMe、多队列存储和部分云盘环境中，不能仅凭 %util=100% 就直接判断设备已经达到绝对性能上限。
仍然应该结合：
await
吞吐量；
队列深度；
业务响应时间；
云盘性能规格
综合判断。
五、系统没有 iostat 怎么办？
Debian、Ubuntu 可以安装：
apt update
apt install sysstat -y安装完成后执行：
iostat -xz 1CentOS、Rocky Linux、AlmaLinux 等系统可以根据实际环境安装：
dnf install sysstat -y较旧系统可能使用：
yum install sysstat -y安装工具本身不会解决 I/O 问题，只是方便进一步定位。
六、使用 iotop 查找高 I/O 进程
如果已经确认磁盘比较繁忙，可以继续定位哪个进程正在大量读写。
执行：
iotop -oPa其中：
-o
主要显示正在产生 I/O 的任务。
-P
按进程显示。
-a
显示累计 I/O。
可能看到类似：
PID USER READ WRITE COMMAND
2841 mysql 12.4 M/s 48.7 M/s mysqld
3922 root 0.0 B/s 31.2 M/s tar -czf backup.tar.gz /www这里就可以发现：
MySQL 正在大量写盘；
同时备份程序也在大量读取网站文件并写入压缩包。
这种情况下 I/O 高就有比较明确的来源。
七、没有 iotop 怎么安装？
Debian、Ubuntu 可以执行：
apt update
apt install iotop -y部分系统也可能提供：
iotop-c具体软件包名称可能因发行版不同而存在差异。
安装完成后通常需要 root 权限运行：
iotop或者：
iotop -oPa八、使用 vmstat 查看 I/O 等待
还可以执行：
vmstat 1常见输出：
r b swpd free si so bi bo us sy id wa
2 6 0 82144 0 0 4120 9620 8 5 32 55这里可以重点观察：
b
bi
bo
wa
其中：
b：处于不可中断等待状态的任务数量。
bi：从块设备读取的数据。
bo：写入块设备的数据。
wa：等待 I/O 的 CPU 时间比例。
如果 b 和 wa 长时间都比较高，就更应该关注磁盘或其他 I/O 资源。
九、数据库为什么容易造成磁盘 I/O 高？
MySQL、MariaDB、PostgreSQL 等数据库都可能产生大量磁盘读写。
常见原因包括：
大量写入；
慢查询；
缺少索引；
大表扫描；
大量临时表；
数据库备份；
Binlog；
频繁 Flush；
内存不足导致缓存命中率下降。
如果通过 iotop 发现：
mysqld长期占用大量磁盘 I/O，不建议直接重启数据库。
应该结合：
慢查询；
数据库日志；
缓存；
业务访问量；
磁盘性能
继续判断。
十、MySQL Binlog 也可能造成持续写入
如果 MySQL 开启 Binlog，在写入量较大的业务中会持续写磁盘。
可以查看数据库目录：
ls -lh /var/lib/mysql/如果看到大量类似：
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003说明存在 Binlog。
不要直接使用：
rm删除正在使用的 Binlog。
如果需要调整 Binlog 保留策略，应通过数据库自身配置和管理命令进行处理。
十一、日志文件可能造成 I/O 持续升高
一些程序发生异常以后，可能每秒输出大量错误日志。
例如：
Docker 应用不断重试；
PHP 程序报错；
接口持续失败；
Nginx Access Log 请求量很大；
系统服务不断输出错误。
可以检查：
du -sh /var/log/*如果服务器运行 Docker，还可以查看：
docker logs --tail 100 容器名称如果同一个错误不断重复，应该优先解决应用本身的问题。
否则即使磁盘性能足够，也会产生大量无意义写入。
十二、备份任务会不会造成 I/O 高？
会。
例如执行：
tar -czf backup.tar.gz /www时，需要：
读取大量网站文件；
压缩数据；
写入新的备份文件。
如果服务器同时正在运行 MySQL、网站和 Docker，就可能出现磁盘竞争。
尤其是：
网站目录和备份文件都位于同一个磁盘；
数据库也在同一个磁盘；
备份时间刚好处于访问高峰；
更容易造成明显卡顿。
因此大型备份任务建议安排在业务低峰期。
十三、rsync 同样可能产生大量磁盘读取
例如：
rsync -avP /www/ backup-server:/backup/虽然最终数据会传输到其他服务器，但本地仍然需要大量读取文件。
如果包含数百万个小文件，扫描目录本身也可能带来较大压力。
可以根据业务情况：
错开备份时间；
限制任务并发；
避免多个备份同时执行。
十四、Docker Volume 为什么会导致 I/O 高？
Docker 本身通常不是 I/O 高的根本原因。
真正产生大量读写的是容器中的应用。
例如：
MySQL 容器；
Elasticsearch；
日志系统；
文件下载服务；
视频处理；
数据库；
持续写日志的程序。
执行：
docker stats可以看到：
BLOCK I/O
但该数值主要适合作为辅助参考。
如果发现某个容器 Block I/O 很高，可以继续使用：
docker logs --tail 100 容器名称以及宿主机：
iotop -oPa进行定位。
十五、Docker 日志过大也会造成磁盘压力
如果 Docker 使用 json-file 日志驱动，而没有配置日志轮转，容器日志可能不断增长。
查看日志路径：
docker inspect --format='{{.LogPath}}' 容器名称检查大小：
du -h 日志文件路径如果单个日志文件已经达到几 GB，需要继续检查应用是否持续刷日志，并配置合理的日志轮转。
不要把直接删除 Docker 正在使用的日志文件作为长期解决方案。
十六、Swap 会影响磁盘 I/O 吗？
会。
当物理内存不足时，Linux 可能频繁使用 Swap。
可以执行：
free -h再执行：
vmstat 1重点观察：
si
so
如果这两个指标长时间持续产生明显数据，同时服务器明显卡顿，说明系统正在频繁进行内存和 Swap 之间的数据交换。
这种情况既会影响内存性能，也会增加磁盘 I/O。
需要继续排查：
内存是否不足；
哪个进程占用大量内存；
是否需要增加内存。
十七、Load 很高但 CPU 不高也可能是 I/O
如果执行：
uptime发现 Load Average 很高，但：
top中 CPU 仍有较多空闲，就可能存在大量等待 I/O 的任务。
继续查看：
vmstat 1如果：
b
wa
明显较高，就更符合 I/O 等待的特征。
还可以查看 D 状态进程：
ps -eo state,pid,ppid,cmd | awk '$1=="D"'大量长时间 D 状态进程也可能导致 Load Average 上升。
十八、检查磁盘是否快满了
磁盘空间不足虽然和磁盘性能不是一回事，但也应该一起检查。
执行：
df -h如果磁盘已经接近：
90%甚至：
100%应该及时处理。
一些数据库、文件系统和程序在磁盘极度不足时，也可能出现明显性能下降或写入异常。
另外检查 inode：
df -i避免大量小文件耗尽 inode。
十九、如何判断是不是正常业务导致的 I/O？
如果 I/O 高只出现在：
每天固定备份时间；
数据库批处理期间；
日志归档期间；
大量文件上传期间；
业务高峰期，
并且任务结束后立即恢复正常，那么可能属于正常业务负载。
这种情况下可以考虑：
调整任务时间；
错开多个高 I/O 任务；
控制并发；
增加缓存；
升级存储性能。
如果 I/O 全天持续很高，则应该进一步定位具体程序。
二十、不要看到 I/O 高就直接 kill 进程
通过 iotop 找到高 I/O 进程以后，不建议直接：
kill -9 PID因为高 I/O 进程可能是：
数据库；
备份；
网站服务；
Docker；
重要业务任务。
强制结束可能造成：
数据库事务异常；
备份损坏；
文件写入中断；
业务中断。
应该先确认进程用途，再决定是否暂停、优化或者正常停止。
二十一、什么时候应该考虑升级磁盘？
如果已经确认：
程序没有异常；
日志正常；
数据库已经合理优化；
没有重复备份；
没有明显 Swap 问题；
高 I/O 来自正常业务持续增长；
磁盘延迟长期较高；
存储性能已经成为业务瓶颈，
就可以考虑升级：
更高性能的云盘；
更高 IOPS；
更高吞吐；
更大的磁盘规格；
或者拆分数据库、日志和业务数据。
升级存储之前，建议先确认真正瓶颈来自磁盘，而不是应用程序异常。
二十二、Linux 磁盘 I/O 快速排查表
| 问题现象 | 优先检查 |
|---|---|
| 服务器很卡但 CPU 不高 | iostat、vmstat |
wa 长期较高 |
磁盘 I/O |
await 明显升高 |
磁盘延迟 |
%util 长期较高 |
磁盘繁忙程度 |
| 不知道哪个程序在读写 | iotop |
| MySQL I/O 很高 | 查询、缓存、Binlog |
| 固定时间 I/O 高 | 备份、Cron |
| Docker Block I/O 高 | 容器内部应用 |
| Swap 频繁读写 | 内存不足 |
| Load 高但 CPU 空闲 | D 状态、I/O 等待 |
建议按照：
top → iostat → iotop → vmstat → 数据库/日志/Docker → Swap → 业务任务
的顺序进行排查。
二十三、仍然无法判断怎么办？
如果服务器磁盘 I/O 长时间较高，并且无法确认具体来源，可以通过莱卡云客户中心提交工单。
建议提供：
服务器 IP；
问题发生时间；
业务类型；
是否运行数据库；
是否运行 Docker；
是否存在定时备份；
服务器是否持续卡顿。
如果方便，可以提供：
iostat -xz 1运行几次后的输出。
还可以提供：
vmstat 1以及：
iotop -oPa相关截图。
请不要在截图中暴露数据库密码、Token 等敏感信息。
总结
Linux 服务器磁盘 I/O 过高时，不建议只看 CPU 使用率。
首先可以通过：
iostat -xz 1观察：
await
%util
以及磁盘读写情况。
然后使用：
iotop -oPa找出正在产生大量 I/O 的进程。
再结合：
vmstat 1检查 I/O Wait、D 状态和 Swap。
比较常见的高 I/O 来源包括：
数据库；
大量日志；
服务器备份；
Docker Volume；
容器日志；
Swap；
大量文件读写。
找到真正产生磁盘压力的业务以后，再决定是优化程序、调整任务时间，还是升级磁盘性能。