Why Redis Memory Remains High After Deleting Keys and How to Fix Fragmentation

A junior teammate noticed that after deleting many unused keys with the top command, Redis memory usage stayed high. This article uses that question to explore why Redis memory may remain fragmented and how to release it correctly.

What Is Memory Fragmentation?

Memory fragmentation occurs when free memory is split into small, non‑contiguous blocks, similar to a train carriage with isolated empty seats that cannot be used together. In operating systems, if an application requests a contiguous block of N bytes but the free space is scattered, the remaining scattered pieces become fragmentation.

Both a 3‑byte and a 2‑byte free region shown in the diagram are examples of fragmentation.

Memory Allocator Strategies

Allocators typically allocate memory in fixed‑size classes (8 B, 16 B, 32 B, …) rather than the exact size requested. Redis can use libc, jemalloc, or tcmalloc; the default is jemalloc. jemalloc rounds a request up to the nearest class size (e.g., a 6‑byte request becomes an 8‑byte allocation). This reduces allocation frequency but leaves unused bytes that become internal fragmentation.

The downside is that the surplus space (e.g., 12 bytes when 20 bytes are requested) contributes to fragmentation and lowers overall memory utilization.

Redis‑Specific Causes

Redis stores variable‑size key‑value pairs. When a value occupies 20 bytes but the allocator gives 32 bytes, the extra 12 bytes become idle and may fragment.

Modifying or deleting a key can also create gaps: a key shrinking from 10 bytes to 7 bytes frees 3 bytes, leaving a 5‑byte hole; deleting a key releases its whole region.

How to Detect Fragmentation

Run the INFO memory command:

INFO memory
# Memory
used_memory:1073741736
used_memory_human:1024.00M
used_memory_rss:1997159792
used_memory_rss_human:1.86G
…
mem_fragmentation_ratio:1.86

The key metric mem_fragmentation_ratio shows the ratio of memory allocated by the OS to memory requested by Redis. A ratio of 1.8 means 80 % more memory is used than needed.

Community‑derived thresholds: >1 && <1.5: normal range. >1.5: fragmentation exceeds 50 %; consider remediation. <1: indicates memory pressure, possible swapping and latency spikes.

How to Clean Fragmentation

The simplest method is to restart Redis, but this risks data loss if persistence is not configured and may cause downtime during AOF/RDB replay.

Since Redis 4.0‑RC3, an active defragmentation feature copies non‑contiguous data into a continuous region, eliminating gaps.

Because Redis is single‑threaded, this copy‑and‑move operation can be CPU‑intensive, so it is controlled by configuration parameters.

Configuration Parameters

Enable automatic defragmentation: config set activedefrag yes Defragmentation starts only when both conditions are met: active-defrag-ignore-bytes 400mb: trigger after at least 400 MB of fragmentation. active-defrag-threshold-lower 20: trigger when fragmentation exceeds 20 % of total allocated memory.

To protect normal request handling, two CPU‑usage limits are available: active-defrag-cycle-min 25: allocate at least 25 % of a CPU cycle to defragmentation. active-defrag-cycle-max 75: stop defragmentation if it would consume more than 75 % of a CPU cycle.

Summary

The high memory usage after key deletion is mainly caused by allocator‑induced internal fragmentation and by variable‑size key modifications or deletions that leave gaps. Use INFO memory and the mem_fragmentation_ratio thresholds to diagnose the issue, and apply Redis’s active defragmentation feature with appropriate active-defrag parameters to reclaim fragmented space without disrupting service.