Redis appendfsync always latency: durability vs throughput trade-offs

Redis AOF persistence logs every write operation, but the appendfsync policy controls when Redis asks the operating system to flush that log to durable storage. That choice determines the trade-off between write latency and the amount of recent data that may be lost after a failure.

appendfsync always makes each acknowledged batch wait for fsync, so slow storage directly increases client latency. appendfsync no leaves flushing to the operating system, so the potential loss window depends on kernel and storage behavior.

The policy is the boundary between durability and latency. This article covers the mechanics of the three fsync modes, their production failure modes, and the signals that reveal disk I/O saturation.

What it is and why it matters

The Append Only File (AOF) reconstructs the dataset on startup by replaying write operations. Redis appends new operations to the AOF and applies one of three flush policies. With always, Redis performs the fsync before replying. With everysec, the flush normally runs once per second in a background thread. With no, Redis writes to the file but does not explicitly request an fsync.

How it works

Redis supports three fsync policies.

Redis can group commands received from multiple clients or a pipeline into one write and one fsync, but always still puts durable-storage latency on the acknowledgement path. A slow fsync therefore appears directly in client response time.

With everysec, Redis normally keeps the fsync off the main thread. If a background flush remains in progress, Redis can delay another AOF write for up to two seconds before attempting the write anyway. This can still create latency when the storage device is saturated.

flowchart TD
    A[Client write batch] --> B[Append commands to AOF]
    B --> C{appendfsync policy}
    C -->|always| D[fsync before reply]
    C -->|everysec| E[background fsync about once per second]
    C -->|no| F[operating system schedules flush]
    D --> G[Client latency follows fsync latency]
    E --> H[About one second of writes may be lost]
    F --> I[Loss window depends on OS and storage]

Common causes

Quick checks

# Confirm that AOF is enabled and identify the fsync policy
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
redis-cli CONFIG GET no-appendfsync-on-rewrite

# Inspect AOF health and background activity
redis-cli INFO persistence | grep -E \
  "aof_enabled|aof_rewrite_in_progress|aof_last_bgrewrite_status|aof_last_write_status|aof_pending_bio_fsync|aof_delayed_fsync"

# Inspect Redis latency events. The monitor must already be enabled.
redis-cli LATENCY LATEST
redis-cli LATENCY HISTORY aof-fsync-always
redis-cli LATENCY HISTORY aof-write-pending-fsync

# Check storage latency on the Redis host
iostat -x 1

Redis latency monitoring is disabled when latency-monitor-threshold is 0. Set its threshold according to the application’s latency requirement; do not copy a universal threshold from another workload.

How to diagnose it

1. Confirm the active policy. Run CONFIG GET appendfsync. Do not infer it from a template or an old configuration file because runtime configuration may differ.
2. Measure client-visible latency. Compare write latency with read-only commands. If only writes slow down, persistence is a stronger suspect than command complexity or network latency.
3. Inspect Redis latency events. The aof-fsync-always event records slow fsync calls under the always policy. aof-write and aof-write-pending-fsync show AOF write stalls, including stalls while another flush is pending.
4. Check AOF state. In INFO persistence, confirm that the last AOF write and rewrite succeeded. A rising aof_delayed_fsync counter or pending background flush jobs indicates that storage is not keeping up.
5. Correlate with the storage device. Use device latency, queue depth, and utilization—not Redis CPU alone. AOF latency can be storage-bound while the Redis process uses little CPU.
6. Look for competing I/O. Check whether the latency begins during an AOF rewrite, RDB snapshot, host backup, log rotation, or another process writing to the same device.
7. Confirm the durability requirement. Decide how much acknowledged data the application may lose after a host or operating-system failure. That requirement determines whether changing the policy is acceptable.

Metrics and signals to monitor

Fixes

Keep appendfsync always

If the application requires the strongest Redis AOF durability policy, keep always and fix the storage path. Remove unrelated I/O from the device, verify that the filesystem and volume honor flush requests promptly, and use storage with stable low fsync latency. Reduce the write rate temporarily if the device cannot keep up.

Benchmark the real persistence volume with the application write pattern. A storage throughput benchmark alone is insufficient because always is dominated by flush latency, not sequential bandwidth.

Change to appendfsync everysec

Redis documents everysec as the default and recommended compromise. It normally keeps fsync work in a background thread and may lose about one second of writes after a failure.

Changing to everysec is a durability decision, not a performance tweak. Make the change only when the application’s recovery-point objective explicitly accepts that loss window, and persist the approved setting in the managed Redis configuration.

Keep appendfsync no

With no, Redis does not request an fsync; the operating system controls flushing. Use it only when the application can reconstruct or discard recent data and accepts a loss window determined by the host’s kernel and storage configuration.

Remove competing I/O

Move backups, log-heavy workloads, and other persistence jobs away from the Redis volume. Schedule AOF rewrites and snapshots so they do not overlap with known write peaks. Recheck Redis latency events and device metrics after each change.

Prevention

• Record the required recovery-point objective before selecting an AOF policy.
• Monitor client write latency together with Redis AOF events and storage latency.
• Enable Redis latency monitoring with a threshold derived from the application’s own latency objective.
• Alert when aof_delayed_fsync increases or the last AOF write/rewrite status changes to err.
• Test persistence behavior on the same storage class used in production, including during rewrites and backups.
• Review runtime configuration after deployments so appendfsync does not drift from the approved policy.

How Netdata helps

• Correlate Redis PING latency and command throughput with disk latency, queue depth, and utilization on the AOF volume.
• Compare current and base AOF size with rewrite activity and host backup windows to identify persistence-related pressure.
• Use the native Redis INFO persistence and LATENCY checks above for fields and events that the current Redis collector does not chart.
• Alert on deviations from the workload’s established latency objective instead of applying a universal latency threshold.

Related guides

• How Redis actually works in production: a mental model for operators
• Redis aof_last_write_status:err: AOF persistence is failing
• Redis Can’t save in background: fork: Cannot allocate memory - diagnosis and fix
• Redis event loop blocked: when one slow command freezes everything
• Redis fork/COW memory storm: why persistence doubles RSS and OOM-kills the box
• Redis latest_fork_usec too high: THP, NUMA, and fork latency
• Redis monitoring checklist: the signals every production instance needs
• Redis rdb_last_bgsave_status:err: diagnosing failed background saves