Mastering Redis Big Key Issues: Detection, Analysis, and Efficient Deletion

Hello everyone, I’ve been busy at work and the article was delayed, but today I share our team’s summary "Redis Big Key Issue Handling Summary", packed with practical tips.

Redis Big Key Issue Handling Summary

What you will gain from this article:

Reasonable key value size is recommended to be less than 10 KB. Oversized values can cause data skew, hot keys, and consume instance traffic or CPU, so they should be avoided at the design stage.

Thus, a value size greater than 10 KB can be used as a reference for judging a big key.

How large is considered a big key?

Alibaba Cloud Redis best practice mentions the 10 KB threshold.

How to discover big keys

1. For string type, use the command --bigkeys The --bigkeys command scans all keys and reports the largest key for each common data type (string, list, set, zset, hash). For strings it reports the value size in bytes; for complex types it reports element counts, which may not directly reflect byte size.

root@vm1:~# redis-cli -h 127.0.0.1 -p 6379 -a "password" --bigkeys

--bigkeys

uses a scan‑based lazy evaluation, so it does not block Redis, but on instances with many keys the command can take a long time; it is recommended to run it on a replica.

Sample output shows the instance has 52,992 keys occupying 1,470,203 bytes. The largest string key uses 157,374 bytes, the largest list key has 153,462 elements, etc.

If the top key for a type is under 10 KB, it indicates no big key for that type, but to list all keys larger than 10 KB you need third‑party tools that scan the RDB file.

2. For non‑string types, two common methods are:

2.1 Use the MEMORY USAGE command (Redis 4.0+).

root@vm1:~# redis-cli -h 127.0.0.1 -p 6379 -a "password"
127.0.0.1:6379> MEMORY USAGE keyname1
(integer) 157481
127.0.0.1:6379> MEMORY USAGE keyname2
(integer) 312583

The MEMORY USAGE command provides an estimated size, which may differ slightly from the --bigkeys summary.

2.2 Use the third‑party Rdbtools utility (Python) to parse Redis snapshot files and list keys larger than a threshold.

# Install
git clone https://github.com/sripathikrishnan/redis-rdb-tools
cd redis-rdb-tools && sudo && python setup.py install

Run the tool to export all keys >10 KB to a CSV:

# rdb dump.rdb -c memory --bytes 10240 -f live_redis.csv

How to gracefully delete big keys

Before Redis 4.0, deleting large keys with DEL could block the server, so scripts were needed to split lists, hashes, or batch‑delete keys.

Since Redis 4.0, the lazy‑free feature allows asynchronous deletion without blocking.

1. Proactive deletion 127.0.0.1:6379> UNLINK mykey The UNLINK command is the asynchronous version of DEL, implemented via lazy‑free: the key is logically removed and the actual memory free is performed in a background I/O thread, avoiding main‑thread blockage even when deleting many big keys.

2. Passive deletion

Redis can automatically evict or expire big keys. In versions prior to 4.0 this could block the main thread. From 4.0 onward, lazy‑free can be enabled for expiration, eviction, and server‑side deletion:

lazyfree-lazy-expire on    # lazy expiration
lazyfree-lazy-eviction on # lazy eviction when memory limit is reached
lazyfree-lazy-server-del on # lazy server‑side deletion

Summary

Use Redis 4.0 or newer.

Employ --bigkeys, MEMORY USAGE, and Rdbtools to identify big keys.

For big keys, always use UNLINK for proactive deletion and enable lazy‑free options for passive deletion.

Fundamentally, avoid creating big keys in the first place.

References

Analysis of Redis 4.0 LazyFree feature.

Cloud Database Redis Development and Operations Specification.