Redis如何监控持久化导致的延迟_开启latency-monitor追踪fsync耗时-Redis-PHP中文网

Redis latency-monitor 能抓到 fsync 延迟，但需手动启用 latency:fsync 事件并设置合理阈值；仅主线程 AOF append 的 fsync 可被监控，RDB/AOF rewrite 子进程的 fsync 不计入；延迟高未必磁盘忙，可能受文件系统、脏页策略或容器 SELinux 标签影响。

redis如何监控持久化导致的延迟_开启latency-monitor追踪fsync耗时

Redis latency-monitor 能不能直接抓到 fsync 延迟

能，但得配对用——latency-monitor 本身不区分延迟来源，它只记录事件耗时；真正把 fsync 拉进监控视野的，是 latency-monitor-threshold 配合 latency monitor 的事件类型识别。默认它不监控 fsync，必须手动开启对应事件。

latency-monitor-threshold 设太低（比如 1ms），会高频打点，影响性能；设太高（比如 100ms），fsync 慢了你也收不到告警
Redis 6+ 默认开启 latency:command 和 latency:slowlog，但 latency:fork 和 latency:fsync 是关闭的，要显式启用
启用方式不是改配置文件就完事——得用 CONFIG SET 同时打开阈值和事件：先 CONFIG SET latency-monitor-threshold 5，再 CONFIG SET latency-events "command,fsync"

怎么确认 fsync 真的被 latency-monitor 捕获到了

靠 LATENCY LATEST 和 LATENCY HISTORY fsync。前者只返回最近一次超阈值的 fsync 记录，后者能看过去 128 条（固定长度），适合排查偶发卡顿。

如果 LATENCY HISTORY fsync 返回空，说明要么没触发超阈值，要么 fsync 事件根本没开——检查 CONFIG GET latency-events 输出里有没有 fsync
注意：RDB 快照期间的 fsync 来自子进程，AOF rewrite 期间的 fsync 也来自子进程，但 latency-monitor 只在主线程上下文记录；所以只有 AOF append 模式下主线程调用的 fsync 才会被捕获（即 appendfsync always 或 everysec 的刷盘时刻）
appendfsync no 时，主线程从不调 fsync，LATENCY HISTORY fsync 永远为空——这不是 bug，是设计如此

为什么看到 fsync 延迟高，但磁盘 I/O 并不忙

常见于使用 ext4 + data=ordered 模式、或 XFS + barrier=1 的文件系统，fsync 不仅刷数据，还要等日志提交完成，而日志落盘可能被其他进程阻塞，或受存储设备写缓存策略干扰。

Linux 的 vm.dirty_ratio 和 vm.dirty_background_ratio 如果设得过高，内核会攒大量脏页，导致 fsync 时被迫回写，耗时陡增
NVMe 盘开启 Write Cache 但未配 barrier，fsync 可能假快真慢——实际数据还在易失缓存里，断电即丢；而 latency-monitor 测到的是系统调用返回时间，不是数据落盘时间
容器环境（如 Docker）挂载卷时用了 :z 或 :Z SELinux 标签，可能引入额外元数据同步开销，也会抬高 fsync 耗时