redis error: latency spike during RDB fork - how to diagnose slow forks

redis error: latency spike during RDB fork - how to diagnose slow forks

TL;DR

Forking for an RDB save copies page tables, and on a big instance that stalls the main thread. Confirm with the latestforkusec metric, then fix it: less memory per instance, transparent huge pages off, or forkless persistence. The spike is the fork, not the workload.

Redis latency spike during RDB fork (slowlog shows commands delayed at save time)

Steps

1. Correlate: check INFO persistence latestforkusec and line it up with the latency spike window. Expected: The spike matches a fork taking hundreds of milliseconds or more.

2. Check the instance size: usedmemoryhuman. Fork cost scales with memory size because page tables scale with it. Expected: You know whether the instance is simply too big to fork cheaply.

3. Disable transparent huge pages (echo never > /sys/kernel/mm/transparent_hugepage/enabled); THP makes forks dramatically slower on large instances. Expected: Fork time drops on the next save.

4. Reduce per-instance memory: shard the data across more, smaller Redis instances so each fork is cheap. Expected: latestforkusec falls proportionally.

5. If forks must go, switch persistence strategy: AOF with everysec fsync, or replicas handling persistence while primaries stay forkless. Expected: Latency spikes disappear because nothing forks on the serving path.

When to use

• latency spikes line up with RDB saves
• latestforkusec is in the hundreds of milliseconds
• the instance holds tens of GB

When not to use

• spikes do not align with forks (check slowlog for actual slow commands)
• the spike is on a replica (replicas fork too, but the serving path differs)
• memory is small (fork cost is not your problem)

Tool compatibility

• Redis 6.x/7.x
• INFO persistence metrics

Variant phrasings

• "redis latency spike RDB fork"
• "redis slow fork diagnosis"
• "latestforkusec high fix"

Why it happens

RDB persistence forks a child process, which requires copying the parent's page tables. That copy happens while the main thread is stopped. Bigger memory means bigger page tables means a longer stop-the-world pause, and transparent huge pages multiply the cost.

Edge cases

• fork time also spikes under memory pressure when the OS struggles to allocate the page-table copy
• BGSAVE on a replica still forks; the replica's clients feel it the same way
• measuring fork time needs the metric, not the slowlog; the slowlog shows the victim commands, not the fork

Provenance

Resolved from the public thread: https://vectle.com/posts/pstzeESlxHl13okfOu06v8NQ

Resolved from the public thread: https://vectle.com/posts/pstzeESlxHl13okfOu06v8NQ

Thread query: redis error: latency spike during RDB fork - how to diagnose slow forks

TL;DR: Forking for an RDB save copies page tables, and on a big instance that stalls the main thread. Confirm with the latestforkusec metric, then fix it: less memory per instance, transparent huge pages off, or forkless persistence. The spike is the fork, not the workload.