Redis and Valkeyintermediate

Redis Big Keys

Why a single large key blocks the server, how to find them safely, and how to delete one without causing an outage.

2 min readIntermediateUpdated 31 Jul 2026Edit this page

A big key is a single key holding a large value — a multi-megabyte string, or a collection with hundreds of thousands of elements. Because Redis executes one command at a time, every operation on that key blocks every other client.

The damage is broader than slow reads:

HGETALL, SMEMBERS and LRANGE 0 -1 on a large collection block for their whole duration.
Deleting one frees a large amount of memory in one blocking step.
Cluster slot migration moves a key as a single blocking operation, so big keys stall resharding.
The reply may be tens of megabytes, filling the client output buffer and pushing memory up.

Finding them

# Sampled, SCAN-based, safe to run against production.
redis-cli --bigkeys
 
# Exact memory usage per key. More expensive; use on a replica if possible.
redis-cli --memkeys

MEMORY USAGE shop:feed:global          # bytes for one key
STRLEN shop:blob:1001
LLEN shop:queue:jobs
HLEN shop:user:1001
SCARD shop:tags:all
ZCARD shop:leaderboard:global

Set a threshold for your deployment and alert on it — a collection above roughly ten thousand elements, or a value above a megabyte, is worth investigating.

Deleting one safely

DEL on a big key blocks the server

DEL frees all the memory synchronously. On a collection with millions of elements that can block for seconds, during which the instance serves nothing. Use UNLINK, which removes the key from the keyspace immediately and frees the memory in a background thread.

UNLINK shop:feed:global

Enable lazy freeing so that eviction, expiry and overwrites also free large objects in the background:

lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes

Shrinking one incrementally

If a collection must be trimmed rather than removed, do it in bounded batches so no single command blocks:

# Trim a huge sorted set down to the newest 100k members, a slice at a time.
while r.zcard(key) > 100_000:
    r.zremrangebyrank(key, 0, 999)
    time.sleep(0.01)

Preventing them

The structural fix is usually modelling: a key that aggregates data for the whole application (shop:feed:global, shop:sessions:all) will grow without bound. Key by entity instead, so growth is distributed across many small keys, each of which stays cheap to read, write and migrate.