When Redis Forks, Measure the Pause and the Copy-on-Write Tail

A Redis persistence cycle can leave two receipts. The first is a short parent-process pause while Redis calls fork(). The second covers the child process writing an RDB snapshot or rewriting AOF while live writes can create copy-on-write memory and compete for host resources. A client graph may blend both into one latency spike even though each clock needs different evidence.

Treat the incident as a small persistence notebook rather than a one-time troubleshooting ladder. Record several ordinary cycles on the same UTC clock, keep the parent and child tracks separate, and compare only like-for-like rows. Do not disable persistence or trigger BGSAVE just to make the graph move. The notebook should reveal whether a measured cost belongs to page-table copy, child overlap, swap, storage, a slow command, or the host.

WordPress operators who still need the application-layer baseline can review how Redis object caching changes request work. This article begins below that layer: Redis and Linux are already running, and the question is what happened during the persistence cycle.

A persistence cycle writes two receipts

According to Redis latency guidance, RDB generation and AOF rewrite require a background process. The parent calls fork() from its main execution path. After the call returns, the child performs persistence work while the parent resumes serving clients.

Parent receipt: the synchronous fork pause

latest_fork_usec reports the most recent fork duration in microseconds. A value of 42000 means 42 ms; it does not declare a universal failure threshold. The meaningful comparison is the service’s own latency budget and an application spike at the same timestamp.

Fork must build memory-management structures for the process address space, including page tables. Larger address spaces generally require more work. Hypervisor and kernel scheduling can also affect the observed pause, so the Redis value belongs beside host evidence rather than inside an isolated screenshot.

Child receipt: persistence overlap

Once the child exists, Linux initially shares memory pages through copy-on-write. Writes made by the parent during the child’s lifetime may cause pages to be copied. A busy write workload, slow child completion, Transparent Huge Pages, swap, CPU contention, or storage pressure can therefore extend the user-visible tail without changing the original fork duration.

INFO persistence exposes active RDB/AOF work and fields such as current_cow_peak, rdb_last_cow_size, rdb_last_bgsave_time_sec, and AOF rewrite results when the running version supports them. Redis INFO documentation tells clients to tolerate missing or unknown properties because the field set changes across versions. Preserve the raw section and interpret only available names.

Build a three-row persistence notebook

Use three rows rather than one dramatic sample: an ordinary cycle before any change, the incident cycle, and a comparable cycle after one approved change. Every row needs the Redis run ID, UTC boundaries, application latency, parent fork duration, child duration/result, copy-on-write evidence, RSS, swap activity, and host CPU/storage notes.

Collection begins with read-only commands. An operator-triggered save changes load and can manufacture the symptom being investigated. Use the deployment’s existing TLS, ACL, socket, or authentication method without placing a password on a shared command line.

date -u +'%Y-%m-%dT%H:%M:%SZ'
redis-cli INFO server
redis-cli INFO persistence
redis-cli INFO memory
redis-cli INFO stats
redis-cli LATENCY LATEST

Before the child appears

Freeze the latency-monitor threshold, process identity, memory state, and persistence configuration before the next naturally scheduled cycle. Redis latency monitoring is disabled when latency-monitor-threshold is zero. If it was already enabled, query its history without resetting it:

redis-cli CONFIG GET latency-monitor-threshold
redis-cli LATENCY HISTORY fork
redis-cli LATENCY DOCTOR

The Redis latency monitor stores timestamped samples above the configured threshold. A fork history point aligned with application p99 is stronger than a current counter alone. When monitoring must be enabled under change control, record the previous value and restore it afterward; one threshold cannot serve every workload.

During and after the child window

Collect host evidence inside the same UTC boundary. vmstat shows runnable tasks, swap-in/swap-out, CPU wait, and scheduling pressure. /proc/PID/smaps can show whether Redis pages are swapped at collection time, subject to process-inspection permissions.

date -u +'%Y-%m-%dT%H:%M:%SZ'
vmstat 1 10
pid=$(redis-cli INFO server | sed -n 's/^process_id://p' | tr -d '\r')
awk '/^Swap:/ {sum += $2} END {print sum " kB swapped"}' "/proc/$pid/smaps"

Swap evidence is time-bound: a nonzero total proves pages are swapped now, not when they moved or whether fork caused the movement. Record storage latency with the site’s normal host telemetry when available. Installing or improvising a new monitoring stack during the event can shift the workload and the timeline.

Treat the table as a comparison contract, not a set of magic numbers. Two rows taken under different datasets, write rates, persistence modes, or host loads should be labeled non-comparable rather than averaged.

Read the parent track without borrowing child evidence

Match latest_fork_usec or LATENCY HISTORY fork to the application clock first. If the client stall is close in timing and magnitude, page-table copy is a plausible owner of the sharp pause. If the application remains slow for seconds after a millisecond-scale fork, the parent track cannot explain the tail by itself.

Intrinsic host latency is a separate baseline. Redis documents redis-cli --intrinsic-latency as a CPU-intensive local test that does not connect to Redis and must run on the server. Use it only in an approved window, then compare quiet and busy periods. When scheduling gaps rise without matching Redis events, CPU steal-time diagnosis provides a more relevant next step than changing persistence.

Large RSS can correlate with slower fork, but correlation is not permission to evict useful data. maxmemory defines data/eviction policy; it does not cap total process RSS. Redis still needs allocator overhead, client and replication buffers, persistence overhead, and copy-on-write headroom.

Read the child track without blaming every copied byte

Child duration and COW size answer different questions. rdb_last_bgsave_time_sec or AOF rewrite duration tells how long the child lived. rdb_last_cow_size records bytes copied through copy-on-write during the operation. A larger COW result does not mean Redis duplicated the full dataset, and a long child does not prove storage alone was slow.

Compare write intensity, child duration, and memory together

When COW rises during a long child window, compare application write rate, child completion time, RSS, swap, CPU wait, and storage latency on the same row. Faster storage may shorten overlap; lower write amplification may reduce copied pages. Neither conclusion is safe until the next comparable cycle supports it.

If Redis or its child was killed, latency is no longer the complete incident. Follow Linux OOM evidence ownership before restarting away the kernel and cgroup record. OOM recovery, memory capacity, and fork latency intersect, but one finding must not stand in for the others.

Kernel settings stay on their own line

Upstream guidance says Transparent Huge Pages can amplify post-fork latency and memory use because writes can copy huge pages. Read both THP and overcommit state before changing either:

cat /sys/kernel/mm/transparent_hugepage/enabled
sysctl vm.overcommit_memory

Apply distribution-supported persistent configuration during an approved window, not only an echo that disappears at reboot. Redis administration guidance recommends vm.overcommit_memory=1 for Linux fork-allocation behavior; that setting does not create RAM or remove COW cost. THP state and overcommit policy solve different problems, so the notebook should keep them in separate columns or notes.

What the notebook cannot authorize

Evidence can rule a path in or out; it cannot silently rewrite the service contract. Keep two common shortcuts outside the notebook’s authority.

A quieter graph cannot choose the durability policy

RDB cadence, AOF mode, appendfsync, and rewrite scheduling define recoverable data loss and restart behavior. Redis persistence documentation describes those tradeoffs. AOF rewrite also forks, so moving from RDB to AOF does not automatically remove the mechanism under study.

Never disable persistence just to remove a spike. State the permitted recovery point, test a restore, and compare representative writes. Operators already planning a platform change should preserve Redis-to-Valkey cutover discipline as its own single-writer and rollback decision.

A server receipt cannot choose the application cache policy

Object Cache Pro scaling choices affect serialization, request work, client behavior, and cache policy. Those application decisions may improve total request latency, but they do not change what latest_fork_usec means. Keep client/plugin evidence and Redis persistence evidence on separate lines so each owner receives the correct work.

Release one change after comparable cycles

Three rows do not guarantee causality, but they expose unsupported stories. Choose the smallest contract the evidence names: reduce an unnecessary address space, shorten a measured child overlap, remove verified swap pressure, persist a supported THP change, adjust durability within an approved recovery objective, or change host capacity after repeatable intrinsic evidence. Record the previous value before release.

Acceptance belongs beside the change, not at the end of a generic checklist: the fork pause stayed inside the application’s agreed stall budget, the child completed without swap or OOM activity, persistence succeeded, and client latency returned to baseline without a durability downgrade. If a clause fails, retain the row and reject the release.

Avoid changing memory policy, THP, storage, and persistence cadence in the same cycle. A quieter graph after four simultaneous changes cannot identify the owner or provide a safe rollback. One comparable cycle, one change, and one explicit loss boundary turn the next persistence event into a decision the team can defend.