You operate a 60 GB Redis instance with append-only-file persistence, and append-only-file rewrites cause periodic latency spikes and near-out-of-memory events. How would you decide when and how rewrites should happen?

## Name the budgets before touching knobs There is no correct rewrite frequency in the abstract. The decision is bounded by two explicit numbers, and a good answer starts by asking for them. **Latency budget.** Every rewrite begins with a `fork()` that stops the server for a period proportional to mapped memory. Measure it, do not estimate it: `latest_fork_usec` after a rewrite on this exact hardware. At 60 GB, several hundred milliseconds is a realistic figure, worse on virtualized hosts. Compare that to client timeouts and to what the calling services do when Redis stalls; a 300 ms stall behind a 100 ms timeout is a partial outage every time it happens. **Recovery budget.** The AOF's size is roughly your restart time, because loading it means replaying it (the base part loads faster, being RDB-format, but the incremental part is replay). Rewriting less often means a larger file means a longer cold start. If the service tolerates 10 minutes of restart, a large file is fine; if it must be back in 60 seconds, the file must stay small and you need frequent rewrites, which pushes you towards the structural fixes instead. The near-OOM part of the symptom adds a third constraint: **memory headroom**, since copy-on-write during a rewrite adds memory proportional to write rate times rewrite duration. ## Fix the host before tuning Redis These are not tuning choices; they are prerequisites, and skipping them makes everything else look worse than it is. - `vm.overcommit_memory=1`. Without it the kernel can refuse the fork outright, and Redis logs a background-save failure while the AOF quietly keeps growing. - Transparent huge pages set to `never`. With THP on, each copy-on-write fault duplicates 2 MB instead of 4 KB, which is very often the direct cause of "rewrites nearly OOM us". - `maxmemory` set so that the dataset plus the expected copy-on-write growth fits physical RAM. On a write-heavy instance the conservative rule is that the dataset should be around half of RAM. - Check `aof_delayed_fsync` and disk latency. If the disk cannot absorb the child's write of 60 GB plus the ongoing appends, the whole rewrite window degrades, not just its start. ## The knobs, and what each one really trades **Raise the thresholds.** `auto-aof-rewrite-percentage 200` or `300`, and `auto-aof-rewrite-min-size` raised well above the default 64 MB so it is meaningful next to a 60 GB dataset. Fewer rewrites, less frequent pain, larger file, slower recovery. Cheap and reversible. **Disable the automatic trigger and schedule it.** `auto-aof-rewrite-percentage 0` plus a cron or scheduler issuing `BGREWRITEAOF` in the quietest window. This is the highest-leverage tuning move because it moves the cost to when the cost is lowest: fewer writes during the window means less copy-on-write, and fewer clients means the fork stall matters less. The price is that you now own the schedule: alert on `aof_current_size` and on `aof_last_bgrewrite_status`, because a schedule that silently stops fills a disk. **`no-appendfsync-on-rewrite yes`.** Removes fsync stalls in the parent while a child runs, at the price of losing durability for the entire duration of the rewrite. Legitimate, but state the trade to stakeholders rather than slipping it in as a performance tweak. **Verify the base is RDB-format** (`aof-use-rdb-preamble yes`, the default since 4.0). If someone turned it off, the file is far larger and slower to load, and the rewrite itself is more expensive. ## The structural answers, which are usually the real ones **Persist on a replica.** Run the master with `appendonly no` and no save points, and let a replica carry AOF and RDB. The master never forks for persistence, so the latency spike disappears from the serving path. The caveats belong in the answer: the replica is asynchronous, so the loss window widens by replication lag, and a master restarting with no persistence comes back empty, so promotion and reseeding procedure must be written down and rehearsed. **Shard.** Ten nodes of 6 GB instead of one of 60 GB reduces fork stall, copy-on-write, rewrite duration and restart time simultaneously, and it removes the single-instance memory ceiling. It is more moving parts, and it is the answer most large deployments converge on. **Question the requirement.** If this instance is a cache whose contents can be rebuilt from a source of truth, the honest recommendation may be no AOF at all: RDB snapshots on a replica for warm restarts, or nothing. A great deal of persistence pain is paid by systems that do not need durability, only warm start. ## How I would sequence it Stabilize first (host settings, thresholds raised, rewrites scheduled off-peak) because those are hours of work. Then plan the structural change (replica-side persistence or sharding) because that is what actually removes the class of problem. Then define the RPO and RTO in writing, and pick the persistence configuration that meets them, rather than inheriting defaults and discovering the numbers during an incident.