Redis maxmemory not set: why every production instance needs a memory limit

On 64-bit builds, Redis defaults maxmemory to 0. In production, this is an incident waiting to happen. A value of 0 means Redis tracks used_memory but enforces no limit. The process grows until the host OS OOM killer intervenes, or until a container memory limit triggers a SIGKILL. Redis dies without warning, restarts into a cold cache, and faces a thundering herd of client reconnections that immediately reapply the same write pressure. The cycle repeats until the configuration is fixed.

The gap between what Redis tracks and what the OS sees makes sizing non-obvious. used_memory includes the dataset, client input and output buffers, and the replication backlog, but it does not reflect allocator fragmentation or copy-on-write overhead generated during fork. The OOM killer uses RSS. An operator watching only used_memory can be surprised by an OOM kill on a node that appeared to have headroom.

Setting maxmemory correctly requires leaving explicit headroom for persistence operations and pairing the limit with an eviction policy that matches the workload. The sections below explain the mechanism, the sizing math, and the operational signals that validate the configuration.

What maxmemory=0 means and why it matters

Without maxmemory, Redis has no trigger for key eviction and no backpressure against growth. Writes, buffer allocations, and module memory all expand the process until an external limit kills it. The default of 0 is acceptable for development or for cache-only instances with strict external controls, but in production it

[OUTPUT TRUNCATED: Response exceeded output token limit.]