Mastering Redis Memory: Analysis, Optimization, and Management Strategies

Redis Memory Analysis

Redis is an open‑source, high‑performance key‑value database that stores data in memory, offering much faster read/write operations than disk‑based databases. Monitoring Redis memory consumption and understanding its memory model are essential for efficient, stable, and long‑term usage.

In production environments, developers typically access Redis through a DaaS platform with read‑only permissions; write operations require change tickets. Memory‑related metrics such as large keys and slow commands are displayed on monitoring dashboards.

Memory Usage Overview

Running INFO MEMORY shows memory statistics. The example screenshots illustrate a memory fragmentation ratio of about 1.08 and that the allocator in use is jemalloc . used_memory_rss is usually larger than used_memory due to fragmentation. When the OS swaps Redis memory to disk, the fragmentation ratio can drop below 1, severely impacting performance.

Redis Memory Distribution

Memory consumption consists of:

Object memory (actual stored data, roughly key size + value size )

Buffer memory (client buffers, replication backlog, AOF buffer)

Memory fragmentation

Object Memory

Redis keys are strings; values can be strings, lists, hashes, sets, sorted sets, bitmaps, HyperLogLog, etc. Proper key‑value design and memory expectation are crucial.

Buffer Memory

Buffer memory includes three parts:

Client buffers

Replication backlog

AOF buffer

Client Buffers

TCP input buffers are uncontrolled (up to 1 GB). Output buffers are configurable via client-output-buffer-limit. Three client types exist:

Slave clients – default limit: client-output-buffer-limit slave 256mb 64mb 60 Pub/Sub clients – default limit: client-output-buffer-limit pubsub 32mb 8mb 60 Normal clients – default limit: client-output-buffer-limit normal 1000 Too many slave connections or remote deployments can increase memory usage; keep the number of slaves ≤ 2.

Replication Backlog Buffer

Since Redis 2.8, a reusable fixed‑size buffer ( repl-backlog-size, default 1 MB) stores partial replication data for slaves.

AOF Buffer

During AOF rewrite, incremental write commands are cached; the buffer size depends on rewrite duration and write volume.

Memory Fragmentation

Redis uses jemalloc by default, which allocates memory in fixed‑size blocks, leading to internal fragmentation. Normal fragmentation ratio is around 1.03. Frequent string appends, SDS lazy reclamation, and expired key cleanup can increase fragmentation.

Mitigation:

Avoid heterogeneous key‑value patterns; align data structures.

Restart Redis to defragment memory when necessary.

Memory Limits and Policies

Configure maxmemory to set an upper bound and trigger eviction when exceeded. Use CONFIG SET maxmemory <size> for dynamic adjustment.

Eviction Policies (maxmemory‑policy)

noeviction – reject writes when limit is reached.

volatile‑lru – evict least‑recently‑used keys with an expiration.

allkeys‑lru – evict LRU keys from the entire dataset (most common).

volatile‑random – evict random expired keys.

allkeys‑random – evict random keys.

volatile‑ttl – evict keys nearest to expiration.

volatile‑lfu – evict least‑frequently‑used expired keys (Redis 4.0+).

allkeys‑lfu – evict LFU keys from the whole dataset (Redis 4.0+).

Set the policy with CONFIG SET maxmemory-policy <policy>. Ensure maxmemory is larger than used_memory to avoid premature evictions.

Memory Reclamation Mechanisms

Redis reclaims memory via:

Expiration – keys are removed lazily on access or by a periodic timer (default 10 times per second).

Eviction – triggered when maxmemory is reached, following the selected policy.

LRU Implementation

Redis approximates LRU using a sample of keys (configurable via maxmemory‑samples) and evicts the least recently used among them. Larger sample sizes improve accuracy but increase overhead.

/* volatile‑lru and allkeys‑lru policy */
else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU ||
         server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU) {
    struct evictionPoolEntry *pool = db->eviction_pool;
    while (bestkey == NULL) {
        evictionPoolPopulate(dict, db->dict, db->eviction_pool);
        for (k = REDIS_EVICTION_POOL_SIZE-1; k >= 0; k--) {
            if (pool[k].key == NULL) continue;
            de = dictFind(dict, pool[k].key);
            sdsfree(pool[k].key);
            memmove(pool+k, pool+k+1,
                sizeof(pool[0])*(REDIS_EVICTION_POOL_SIZE-k-1));
            pool[REDIS_EVICTION_POOL_SIZE-1].key = NULL;
            pool[REDIS_EVICTION_POOL_SIZE-1].idle = 0;
            if (de) { bestkey = dictGetKey(de); break; }
        }
    }
}

Linux Considerations

Copy‑on‑write causes parent and child processes to share physical pages; writes duplicate pages, increasing memory usage. Transparent Huge Pages (THP) enlarge page size to 2 MB, slowing fork operations—disable THP for high‑throughput workloads.

Set vm.overcommit_memory = 1 to allow Redis to allocate all requested memory and prevent fork failures.

Practical Recommendations

Configure maxclients appropriately.

Estimate per‑operation data size and network latency.

Avoid heavy commands like KEYS in production.

Monitor memory usage in real time and set alerts for high usage.

Ensure maxmemory exceeds used_memory by 1–2 GB to accommodate fragmentation and OS overhead.