直接看 %util 和 await，结合 rkB/s、wkB/s 与 avgrq-sz 判断缓存系统是否处于“假命中”或“穿透写”状态：avgrq-sz < 8 + w/s 高 + %util 40%～70% 表明小而密随机写；await 显著高于 svctm 暗示队列堆积；wkB/s 远超预估则暴露写放大；%iowait > 15% 且 avgqu-sz > 2 表示 CPU 已感知 I/O 延迟。
直接看 %util 和 await 两个核心指标，再结合 rkB/s、wkB/s 与 avgrq-sz 判断缓存系统是否在“假命中”或“穿透写”场景下隐性压垮磁盘。
重点关注缓存层下的真实磁盘负载
缓存系统（如 Redis 持久化、MySQL InnoDB buffer pool、Elasticsearch segment flush）常给人“IO很低”的错觉，但 iostat 显示的设备级压力可能已悄然升高。关键在于区分：是缓存拦截了请求（低压力），还是缓存失效/刷盘/合并导致突发 I/O（高压力）。此时不能只看瞬时 tps，而要观察连续采样中的波动规律。
- 用 -x -d -k 1 5 或 -x -d -m 2 10：固定间隔连续采样，避免单次快照失真；-m 更适合缓存系统（通常吞吐量大），-k 对小 IO 场景更敏感
- 跳过 loop、sr0 等非物理设备：专注 sda/nvme0n1/dm-0 等后端块设备，尤其注意 LVM 或加密卷（dm-*）是否成为瓶颈放大器
- 对比缓存活跃期与空闲期的 %util 基线：若空闲时 %util ≈ 2%～5%，而缓存批量落盘时突增至 85%+，说明刷新策略（如 Redis AOF rewrite、MySQL checkpoint）正在冲击磁盘
识别缓存穿透/写放大引发的异常模式
缓存系统压力不总体现为高吞吐，更多表现为“小而密”的随机写——这正是 iostat 中 avgrq-sz 和 r/s+w/s 联合揭示的信号。
- avgrq-sz < 8（即 <4KB） + w/s 高 + %util 中等（40%～70%）：典型缓存日志刷写（如 WAL、journal）或元数据更新，IOPS 密集但吞吐不高，易造成队列堆积
- await 显著高于 svctm（例如 await=25ms，svctm=0.8ms）：说明 I/O 在队列中排队等待，不是磁盘慢，而是请求太多——常见于缓存批量 evict 后触发集中 writeback
- wkB/s 远高于应用层预估写入量：比如 MySQL 设置 innodb_io_capacity=200，但 iostat 显示 wkB/s 持续 50MB/s，暗示 doublewrite buffer、change buffer merge 或 purge 线程正在后台放大写流量
关联 CPU 的 %iowait 与 avgqu-sz 定位阻塞源头
缓存系统常多线程并发访问磁盘，iowait 和队列长度能反映内核调度层是否已成为瓶颈。
- %iowait > 15% 且 avgqu-sz > 2：CPU 级别已感知到 I/O 延迟，此时即使 %util 未达 100%，服务响应时间（P95 latency）大概率已劣化
- 对比 r_await 与 w_await：若 w_await 是 r_await 的 3 倍以上，说明写路径（如 fsync、log sync）拖慢整体，需检查缓存的持久化策略（AOF everysec vs always）、文件系统挂载选项（data=ordered vs writeback）、是否启用 barrier
- 观察 rrqm/s 与 wrqm/s：高合并值（如 wrqm/s > w/s × 0.6）说明内核已在尽力优化，但仍无法缓解压力——这时优化方向应是减少写频次（如调整 Redis maxmemory-policy）、增大刷盘间隔，而非调优磁盘本身
实战建议：三步快速归因
面对一个响应变慢的缓存服务，按顺序执行：
- 第一步：运行 iostat -dxm 2 5 | grep -E "(Device|sda|nvme|avg-cpu|util|await|w_await)"，聚焦主存储设备和 CPU iowait
- 第二步：若 %util > 70% 或 await > 15ms，立即查对应进程：pidstat -d 1 5 或 iotop -oP，确认是 mysqld、redis-server 还是内核 flusher_* 线程在驱动 I/O
- 第三步：结合业务节奏交叉验证——例如定时备份、凌晨 compaction、缓存预热任务是否与 iostat 高峰重叠；若重叠，优先调整这些任务的 I/O 优先级（ionice）或限速（cgroups blkio.weight）
