Why Redis Requires vm.overcommit

Why Redis Requires vm.overcommit_memory=1

Requiring vm.overcommit_memory = 1 in Redis configuration mainly addresses a core problem: during background persistence (such as BGSAVE / AOF rewrite), Redis may be denied a large memory allocation by the Linux kernel, causing the operation to fail.

Core Reason: Guarantee Background Persistence Succeeds

Redis is an in-memory database. When performing BGSAVE (producing an RDB snapshot) or an AOF rewrite, the main process forks a child process. In theory this child needs to allocate physical memory equal to the size of the parent (the main Redis process). Although modern Linux uses Copy-on-Write so the child actually consumes far less memory than the theoretical amount, the kernel still performs an “overcommit” check at fork time.

When vm.overcommit_memory is left at its default value of 0, the kernel uses a heuristic, relatively conservative check that may reject a memory request that “looks too large” even when the system actually has enough memory. This rejection makes Redis’s fork fail, which in turn prevents persistence from proceeding.

Parameter Details and Configuration Advice

vm.overcommit_memory has three modes; understanding them is essential for configuring Redis:

Value	Mode	Kernel check policy	Impact on Redis & recommended use
`0` (default)	Heuristic check	Estimates risk from total memory, committed memory, and `overcommit_ratio`; may reject the request.	May cause BGSAVE/AOF rewrite failures. Not recommended for Redis.
`1`	Always allow	The kernel always approves any memory request, regardless of current memory state.	Maximizes the chance fork succeeds; this is Redis’s officially recommended value. Ensure the system has swap space as a last-resort buffer to avoid extreme OOM.
`2`	Never exceed the limit	Requests may not exceed the hard limit *`total memory overcommit_ratio + swap`**.	Safest, but also most likely to cause fork failures. Only consider it when you can precisely calculate and set a sufficiently large limit. Production needs careful tuning.

How to Check and Set It

1. View the current value

cat /proc/sys/vm/overcommit_memory

2. Temporary setting (lost on reboot)

sudo sysctl vm.overcommit_memory=1

3. Permanent setting (recommended)

Edit /etc/sysctl.conf, adding or modifying a line:

vm.overcommit_memory = 1

Then apply the configuration:

sudo sysctl -p

Setting vm.overcommit_memory=1 alone is sometimes not enough—you should also pay attention to Transparent Huge Pages (THP).

This is another kernel feature that commonly causes latency and problems in Redis. Redis officially strongly recommends disabling it, because THP produces large memory pages that hurt the performance and memory usage of the forked child process.

# Temporarily disable THP
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

# Permanent disable: add the command to a startup script such as /etc/rc.local

Summary

In short, setting vm.overcommit_memory = 1 for Redis is about giving the kernel a “green light” so it always permits the fork’s memory allocation under any circumstance, thereby keeping the background persistence mechanism reliable. This is one of the key OS-tuning steps for running Redis stably in production, and it is normally done together with disabling Transparent Huge Pages (THP).