Redis如何分析持久化产生的磁盘IO延迟_使用iostat监控性能-Redis-PHP中文网

iostat应重点关注%util、await、svctm三列，其中%util＞90%且await＞20ms表明磁盘瓶颈；aof重写时iostat的wkb/s含文件系统开销，高于redis逻辑aof大小；rdb为短时高压io，aof重写为中时长稳定io，需结合日志区分。

redis如何分析持久化产生的磁盘io延迟_使用iostat监控性能

Redis执行 RDB 快照或 AOF 重写时，会集中写入大量数据，直接反映在磁盘IO上。用 iostat -x 1 每秒采样，重点关注这三列：%util（设备忙时占比）、await（单次IO平均等待毫秒）、svctm（实际服务时间，已弃用，忽略）。

若 %util 持续 >90% 且 await >20ms，说明磁盘已成为瓶颈，不是Redis本身慢，而是写不进去。

%util 高但 await 低（
await 显著升高（>50ms）+ %util 中等（60%~80%）：更危险——说明IO队列堆积，请求在内核层排队，常见于AOF追加+fsync同步场景
同一台机器跑多个Redis实例？务必用 iostat -x -d /dev/sdb 1 指定设备，避免被系统盘干扰

因为 iostat 统计的是裸设备写入量（含文件系统元数据、日志、对齐填充），而 redis-cli info persistence 中的 aof_current_size 和 aof_base_size 是逻辑AOF文件大小，二者不在同一层级。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

Rewrite过程实际触发的是 fork() 后子进程把内存数据序列化成新AOF，再原子替换——这个写入是密集顺序写，iostat 的 wkB/s 反映真实物理写入带宽
如果启用了 appendfsync everysec，主进程仍持续追加新命令到旧AOF，这部分IO和rewrite IO叠加，iostat 看到的是总和
SSD上可能看到 avgrq-sz（平均请求扇区数）突然变大（>128），这是内核合并了多个小写为大IO，属正常优化，不代表Redis在发大包

不能只看 iostat，必须联动Redis日志和监控指标。RDB和AOF的IO模式有本质差异：

RDB是短时高压：fork后子进程一次性dump，iostat 会看到几秒内 wkB/s 拉满，之后归零；对应日志出现 "Background saving started by pid"
AOF rewrite是中时长稳定写：持续几十秒到几分钟，wkB/s 波动较小但持续高位；日志出现 "Starting automatic rewriting of AOF" 或 "Background AOF rewrite finished successfully"
检查 redis-cli config get save 和 config get auto-aof-rewrite-percentage，确认触发条件；若 save ""（禁用RDB），那所有IO尖峰都来自AOF

延迟在磁盘层，Redis进程本身无感知，所以 INFO commandstats 或 SLOWLOG 都可能完全正常。此时必须跳出Redis看底层：

运行 iostat -x 1 5 同时，在另一终端执行 cat /proc/diskstats | grep sdb，对比 io_ticks（设备忙的时间，单位ms）是否与 %util 趋势一致——排除iostat采样抖动
检查 dmesg -T | tail -20，找是否有 end_request: I/O error 或 ata timeout，机械盘掉速或SSD固件bug常表现为延迟突增而非直接失败
确认Redis的 dir 配置路径是否落在LVM、加密卷（LUKS）、NFS或CephFS上——这些层会放大延迟，iostat 看到的是最终设备，但瓶颈可能在上层