Understanding Redis Maxmemory and Eviction Policies

This article explains how Redis memory usage is limited by the maxmemory configuration, how to view and modify it, and the default values on 32‑bit and 64‑bit systems.

Use CONFIG GET maxmemory to see the current limit and INFO MEMORY for detailed memory statistics. The limit can be changed by editing redis.conf or by running CONFIG SET maxmemory <bytes> .

Redis triggers an eviction policy only when memory usage reaches the configured maxmemory . Six original eviction strategies are supported: volatile-lru , volatile-ttl , volatile-random , allkeys-lru , allkeys-random , and noeviction . Since version 4.0, two LFU‑based policies were added: volatile-lfu and allkeys-lfu .

The naming convention allkeys-xxx means eviction can occur on any key, while volatile-xxx applies only to keys with an expiration time.

config set maxmemory 2147483648   # set to 2 GB (bytes)

The enumeration of policies is defined in config.c as maxmemory_policy_enum[] (list shown in the original source).

Current policy can be inspected with CONFIG GET maxmemory-policy and changed with CONFIG SET maxmemory-policy <policy> . Changes made via CONFIG SET are volatile and disappear after a restart; permanent changes require editing redis.conf and restarting.

Guidelines for choosing a policy:

For cache‑optimisation, prefer allkeys-lru or allkeys-lfu .

To avoid loss of critical data, use noeviction and monitor memory.

If TTL is important, select a volatile-xxx policy.

If a single Redis instance cannot hold the required data, a sharded cluster can be used. Before Redis 3.0, external proxies such as Twemproxy or Codis were common; since Redis 3.0 the native Redis Cluster is the preferred solution.

In production, memory should be monitored with INFO MEMORY or external tools like Prometheus + Grafana, and best practices such as choosing appropriate data types, avoiding large keys, and cleaning up stale data should be followed.

Key take‑aways:

Set an appropriate maxmemory and eviction policy based on the workload.

Consider Redis Cluster when a single node’s memory is insufficient.

Continuously monitor memory usage and apply optimisation techniques.

References: Redis eviction documentation (https://redis.io/docs/reference/eviction/), Twemproxy, Codis, Redis Cluster tutorial.