🚨 Redis Error Guide: 'Can't save in background: fork: Cannot allocate memory' — Fix Redis fork/COW OOM

Overview

Redis raises this when a background save (BGSAVE, automatic RDB snapshot, or BGREWRITEAOF) tries to fork() a child process and the kernel refuses the memory reservation:

Can't save in background: fork: Cannot allocate memory

You will also see it in the Redis log around save time:

# Failed opening the RDB file dump.rdb (in server root dir /var/lib/redis) for saving: ...
# Background saving error

And the tell-tale kernel warning that explains the root cause:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.
To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf ...

Persistence is how Redis writes RDB snapshots and rewrites the AOF. Redis forks a child to do this so the parent keeps serving traffic. fork() uses copy-on-write (COW): the child shares the parent’s memory pages until either process writes to a page, at which point the kernel copies it. Linux must be willing to reserve enough address space for the worst case; when vm.overcommit_memory is 0 (heuristic) and free memory is tight, the kernel denies the fork and the save fails. If stop-writes-on-bgsave-error is on (the default), Redis then rejects writes until a save succeeds.

Symptoms

• BGSAVE / BGREWRITEAOF return an error or the log shows Background saving error.
• LASTSAVE timestamp stops advancing; rdb_last_bgsave_status:err in INFO persistence.
• With defaults on, writes start failing with MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk.
• The startup log carries the overcommit_memory is set to 0 warning.
• Failures cluster at high memory usage or during write bursts.

Common Root Causes

• vm.overcommit_memory=0 — the kernel’s heuristic denies the fork when it thinks memory is tight, even though COW rarely needs a full copy.
• Not enough free RAM for COW — under heavy writes during the save, many pages get copied; the peak can approach 2x used_memory. A box sized only for the dataset has no headroom.
• maxmemory set too close to physical RAM — Redis fills memory, leaving nothing for the fork’s copied pages or the OS page cache.
• No swap plus a large dataset — no overflow room when COW pages accumulate.
• Other processes on the box — a co-located app consuming RAM at save time.
• Transparent Huge Pages (THP) enabled — inflates COW copies and latency during fork.

Diagnostic Workflow

Confirm the persistence state and last save result:

redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|rdb_last_bgsave_status|aof_last_bgrewrite_status|aof_rewrite_in_progress'
redis-cli LASTSAVE

Check the memory picture — how close Redis is to the ceiling and the box’s free RAM:

redis-cli INFO memory | grep -E 'used_memory:|used_memory_rss:|maxmemory:|maxmemory_policy:'
free -m
cat /proc/meminfo | grep -E 'MemFree|MemAvailable|CommitLimit|Committed_AS'

Verify the kernel overcommit setting and THP (the two most common fixes):

sysctl vm.overcommit_memory          # want 1, not 0
cat /sys/kernel/mm/transparent_hugepage/enabled   # want [never]

Read the Redis log for the exact failure and the overcommit warning:

sudo journalctl -u redis-server --since '1 hour ago' | grep -iE 'fork|background sav|overcommit'
sudo tail -n 100 /var/log/redis/redis-server.log

Look at write churn — heavy writes during a save multiply COW copies:

redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec|total_writes_processed'

Example Root Cause Analysis

A 16 GB VM runs Redis as a cache with used_memory around 11 GB and maxmemory 12gb. Automatic RDB snapshots (save 900 1) begin failing every afternoon with Can't save in background: fork: Cannot allocate memory, and shortly after, writes are rejected with MISCONF.

sysctl vm.overcommit_memory returned 0, and free -m showed only ~3 GB available at peak. During the afternoon write burst, COW copied a large fraction of the 11 GB dataset, so the fork’s worst-case reservation exceeded what the heuristic allowed and the kernel denied it. The overcommit_memory is set to 0 warning had been in the log since startup.

Fix: set vm.overcommit_memory=1 persistently, lowered maxmemory to 9gb to leave COW headroom, added swap as a safety overflow, and disabled THP. Snapshots succeeded from the next cycle; rdb_last_bgsave_status returned ok and writes were accepted again.

Prevention Best Practices

• Set vm.overcommit_memory = 1 in /etc/sysctl.conf (and sysctl -p) on every Redis host — this is the single most impactful fix.
• Size RAM so peak COW fits: keep used_memory well under physical RAM; a common rule is maxmemory no more than ~50-60% of RAM on write-heavy persistence workloads.
• Disable Transparent Huge Pages (never) to shrink COW copies and fork latency.
• Keep some swap as an overflow cushion so a transient COW spike does not kill the save.
• Avoid co-locating memory-hungry processes with a persistence-enabled Redis.
• Consider running persistence on a replica (save "" on the primary, snapshots on the replica) to remove fork pressure from the write path.
• Alert on rdb_last_bgsave_status:err and aof_last_bgrewrite_status:err so you catch failures before writes stall.

Quick Command Reference

# Enable memory overcommit (fixes most fork failures)
sudo sysctl -w vm.overcommit_memory=1
echo 'vm.overcommit_memory = 1' | sudo tee -a /etc/sysctl.conf

# Disable Transparent Huge Pages
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

# Give COW headroom
redis-cli CONFIG SET maxmemory 9gb
redis-cli CONFIG REWRITE

# Trigger and verify a save
redis-cli BGSAVE
redis-cli INFO persistence | grep rdb_last_bgsave_status
redis-cli LASTSAVE

# Temporary relief: stop blocking writes while you fix root cause
redis-cli CONFIG SET stop-writes-on-bgsave-error no

Conclusion

fork: Cannot allocate memory is almost never a bug in Redis — it is the Linux kernel refusing the copy-on-write reservation a background save needs. Set vm.overcommit_memory=1, leave real RAM headroom below maxmemory for COW, disable THP, and keep an overflow of swap. Do those four things and BGSAVE/BGREWRITEAOF succeed reliably, and your writes stop stalling behind failed snapshots.