磁盘IO打满怎么办？区分IO、空间、CPU与内存问题
磁盘IO繁忙、空间满、内存紧张和CPU繁忙都可能伴随卡顿，但处理方向不同。先记录异常时间、时区和受影响业务，在卡顿发生时采样，再与同一实例正常时段比较。单次峰值或跑分不能直接证明硬件故障，也不足以决定升级哪种资源。
先取得卡顿时的基础数据
Linux：在服务器终端分别执行以下只读命令，top按q退出。记录输出时间，并核对网站、数据库或远程操作是否同时变慢。
top
free -h
df -h
df -i| 检查项 | 怎样判断 | 下一步 |
|---|---|---|
| CPU | 在top连续观察占用较高的进程，并记录进程名称；一个瞬时百分比或load数值不能单独说明原因。 | 对照并发请求、压缩转码、编译、定时任务和近期发布；CPU高的进程未必也是主要磁盘读写来源。 |
| 内存 | free的available估算可供新应用使用而不必交换的内存。free较少不一定不足；Swap已用量也不等于此刻正在频繁换页。 | 若available持续偏低且应用延迟、换页活动同步增加，继续核对服务内存增长、缓存、并发和限制。 |
| 空间与inode | df -h看容量，df -i看inode；找到业务目录对应的挂载点。容量有余量时，大量小文件仍可能耗尽inode。 | 确认增长来自日志、上传、缓存还是备份，核对保留要求，再安排轮转、归档或清理；不要直接删未知目录或数据库文件。 |
Windows：打开任务管理器，按CPU、内存排序识别进程，在“性能”中观察趋势；需要查磁盘活动时打开资源监视器，对照进程、读写和响应时间。另查业务所在卷的可用空间。保留进程名称和异常时刻，不只截总占用百分比。
Linux：用iostat区分IO等待与设备负载
如果系统已安装sysstat，在卡顿期间执行：
iostat -x -y 1 5此例每隔1秒采样，共5份报告；-y跳过默认首份“自开机以来”的统计。命令不存在或版本不支持时，保留现有监控和工具版本，不必在故障高峰临时安装或改系统。
await或分列的r_await、w_await是IO请求平均完成时间，包含排队与服务时间，通常以毫秒显示。aqu-sz表示平均请求队列长度，需和同一设备的读写量、请求数、等待时间及业务响应一起看。%util不是空间占用率。串行设备接近100%可提示饱和；现代SSD、RAID等可并行处理请求，不能统一用这一列判断性能上限，更不能直接判断磁盘损坏。
若持续读写时等待和业务延迟一起升高，继续查读写来源；若只在额外跑分时升高、结束后恢复，先停止不必要的测试并区分测试负载与真实业务。没有适合所有云盘和业务的固定毫秒阈值。
Linux：定位发起读写的任务
已安装sysstat且有相应权限时，可在同一异常时段执行：
pidstat -d 1 5按PID、Command识别任务，对照kB_rd/s和kB_wr/s寻找活跃读写，再与备份、数据库、日志和同步任务核对。默认只列活跃任务，未出现某进程不证明它没有IO；工具不可用时不必临时安装。
确认业务原因后再调整
将采样时间与慢请求、日志写入、批处理、备份和流量变化对齐。确认责任服务、业务影响和回退方式后，选择优化请求、降低并发或错开重任务等方案，并复查同一组指标。不要把杀进程、清缓存、删文件或重启数据库当作通用第一步。
正常业务下仍持续受限时，先区分需要的是CPU、内存、IOPS、吞吐还是容量，再评估优化、拆分或升级。
何时提交工单
无法登录、出现文件系统只读或设备异常，或持续卡顿仍定位不清时，可提交工单，提供：
- 实例标识、地区、操作系统与工具版本，异常时间和时区。
- 受影响业务、持续时长、近期变更，以及正常和异常时段的多组采样。
- 已确认的进程、备份或数据库任务，已做调整及结果。
只附相关日志片段，遮去密码、令牌和客户信息。资源截图有助于定位，但不能独立确认宿主机或硬件责任。
相关文档：查看CPU、内存与磁盘用量 · 同配置实例有效对照