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指定设备，避免被系统盘干扰
为什么aof-rewrite期间iostat显示的write kB/s远超redis-cli info里的aof_current_rewrite_time_sec计算值
因为 iostat 统计的是裸设备写入量（含文件系统元数据、日志、对齐填充），而 redis-cli info persistence 中的 aof_current_size 和 aof_base_size 是逻辑AOF文件大小，二者不在同一层级。
Redis Skill - 高性能缓存管理
下载
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在发大包
如何区分是RDB还是AOF导致的IO尖峰
不能只看 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
用iostat抓到IO延迟高，但Redis没报错，下一步查什么
延迟在磁盘层，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看到的是最终设备，但瓶颈可能在上层
磁盘IO延迟问题里，最易被忽略的是“非Redis配置项”：比如ext4挂载时没加 noatime,nobarrier，或者云盘IOPS配额被其他进程吃光。盯着Redis参数调，往往白费功夫。
