Redis BGSAVE fork fails with 'fork: Cannot allocate memory' on 512MB cloud VM during snapshot

Environment

Redis 6.2.13 running on a 512 MB single-vCPU cloud VM (Ubuntu 20.04), dataset ~350 MB of keys, RDB snapshots configured (save 900 1), swap disabled by default, vm.overcommit_memory=0.

Symptoms

Periodic RDB snapshots trigger a server pause; clients get slow responses and eventually Redis is killed by OOM killer with kernel log showing 'oom_reaper' and 'Killed process <redis-server> (forked)'. BGSAVE fails with 'fork: Cannot allocate memory' in redis log.

Observations

free -m shows <20 MB free before BGSAVE; top shows Redis rss ~360 MB; no swap configured; redis-cli INFO persistence shows last_bgsave_status = err. Attempts to run BGSAVE manually fail with same error. System logs show kernel out-of-memory events at time of BGSAVE attempts.

Already attempted

Increased save interval to reduce frequency (didn't help for immediate BGSAVE attempts), set vm.overcommit_memory=1 temporarily, enabled appendonly yes (made memory worse), restarted Redis to clear memory but dataset size remained large. Created a 1GB swap file and observed BGSAVE completes occasionally but at cost of extreme I/O and long pause.

Question

How can I get reliable persistence from Redis on a constrained 512 MB VM without risking the server being OOM-killed every time BGSAVE runs, and what configuration changes or architecture changes avoid this fork-memory doubling problem?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Insufficient physical RAM for fork() + dataset (COW overhead) causing fork failure or OOM. 95%

Swap disabled and vm.overcommit_memory=0, so kernel refuses to allow fork when virtual memory cannot be guaranteed. 90%

Memory fragmentation increasing actual anonymous memory consumption beyond rss estimate. 25%

Summary

Redis uses fork() to create a child process that writes the RDB snapshot; fork requires enough virtual memory for copy-on-write overhead. On small VMs with large datasets and no swap, the kernel may refuse fork or trigger OOM when COW pages accumulate. Enabling swap can allow BGSAVE to complete but causes heavy disk I/O and pauses. Alternatives include avoiding forks by using replication: creating a replica on a larger instance and triggering BGSAVE there, using append-only file (AOF) with incremental fsync strategies, or switching to Redis modules/features that reduce memory pressure. On Redis 6.x, there is no built-in RDB alternative that avoids fork; Redis 7 adds some improvements but still uses fork for RDB.

Suggested Fixes

Diagnostic step 1

Immediate low-effort mitigation: enable a swap file (e.g., 1–2x dataset delta) to allow fork to complete. Create and enable swap with fallocate/dd, mkswap, swapon and add to /etc/fstab (test in maintenance window). Monitor I/O impact.

Diagnostic step 2

Short-term architectural options: - Provision a larger VM with more RAM for the Redis primary to handle fork overhead. - Create a replica on a larger instance and run BGSAVE there; promote replica as primary if needed. - Reduce dataset memory: expire old keys, use volatile-ttl, or prune large keys.

Diagnostic step 3

Configuration options to reduce memory pressure: - Set vm.overcommit_memory=1 only as a temporary test (understand OOM risk). - Enable active memory defragmentation (activedefrag) and maxmemory policies to cap dataset size. - If using AOF, consider appendfsync everysec and AOF rewrite scheduling that avoids simultaneous heavy memory use.