现象：应用响应明显变慢，监控看到磁盘 IO 使用率长期接近上限，但 CPU 并不高。以下是社区整理的排查思路，供遇到同样问题的同学参考。
先确认「打满」指的是什么
IO 相关的指标有好几个，含义并不相同，混着看容易误判：
- 使用率与饱和度：设备有 IO 请求在处理的时间占比。这个值高说明设备忙，但并不直接等于性能不够。
- 每秒读写次数（IOPS）：小块随机读写场景下最容易先到达上限，典型来源是数据库与大量小文件操作。
- 吞吐（MB/s）：大文件顺序读写场景下的瓶颈，典型来源是备份、日志写入、文件传输。
- 平均等待时间：请求从发出到完成的耗时，这是最贴近业务感受的指标。等待时间明显升高，说明确实已经影响性能了。
先看清是哪一项到达上限，再决定优化方向：IOPS 打满要减少随机小 IO，吞吐打满要控制大流量写入，等待时间长则要综合判断队列深度。
定位到进程与文件
用系统自带的 IO 统计工具按进程查看读写速率，找出消耗最高的那个；再用文件级工具确认它具体在读写哪些文件。这一步能把范围从「机器慢」缩小到「某个进程在写某个文件」，后面就好办了。
常见的几类元凶：
- 日志：调试级别日志忘记关、日志没有轮转、异常循环导致疯狂打印堆栈。这类问题在发布后突然出现，优先怀疑。
- 数据库：慢查询触发大量随机读、事务过大导致刷盘压力、临时表落到磁盘、缓冲池配置过小使命中率下降。
- 交换分区：内存不足开始使用 swap，会同时表现为 IO 升高与响应变慢。先看内存使用率，如果 swap 在增长，根本问题是内存不够或存在内存泄漏。
- 备份与同步任务：定时备份、文件同步、数据导出撞上了业务高峰。
- 异常进程：陌生进程持续大量读写磁盘，需要结合进程路径、启动时间与外连情况判断是否被入侵，按应急流程处理。
先止血，再优化
业务已经受影响时，先用可逆的手段恢复：调整或暂停非关键的定时任务、把日志级别调回正常、临时限制某个进程的 IO 配额、必要时临时升级到更高 IO 能力的存储类型。这些操作能在几分钟内见效，为后续排查争取时间。
中长期优化方向
- 存储类型与规格匹配负载：数据库等随机小 IO 密集的负载，需要选择 IOPS 能力更强的存储；日志、备份等顺序大流量负载，更适合吞吐型存储或独立的盘。
- 分离负载：把数据库、日志、应用部署在不同的盘甚至不同的实例上，避免互相争抢。数据库更建议直接使用云数据库服务，把存储层的运维交给平台。
- 减少不必要的写入：日志按级别输出并配置轮转与压缩、批量写入代替逐条写入、缓存热数据减少回源读盘。
- 数据库层面：优化慢查询与索引，避免全表扫描带来的大量随机读；合理设置缓冲池，让热数据尽量留在内存。
- 应用层面：检查是否存在循环内频繁读写文件、大对象序列化落盘、未关闭的文件句柄等代码问题。
把 IO 纳入常规监控
很多团队只监控 CPU 和内存，磁盘只在出事时才看。建议把 IO 使用率、IOPS、吞吐、平均等待时间、swap 使用量都接入监控，并按业务重要性设置告警阈值。同时保留一段时间的历史数据，便于对比「今天和上周有什么不同」——这类问题的定位往往就靠趋势对比。
小结：IO 打满的排查顺序是：先看哪项指标到上限，再定位到进程与文件，然后判断是日志、数据库、swap 还是任务导致，先止血再做结构性优化。跳过前两步直接换硬件，很可能换了之后问题依旧。
需要外部支持时，可以找安徽卓牛
安徽卓牛为客户提供云上的性能排查、监控体系搭建与运维托管服务，能够结合阿里云的计算、存储与可观测产品，帮助团队定位瓶颈并给出优化方案。若你希望就当前的性能问题做一次现状评估，可通过官网在线客服联系安徽卓牛，获取针对性建议。具体方案与费用以实际评估和报价为准。
#磁盘IO#性能排查#ECS#求助