One family dominating
Three quarters of the sample under one prefix, which is where growth comes from
session:a session:b session:c cache:x
Redis Keyspace Prefix Analyzer
Paste keys from redis-cli --scan, one per line. Grouping by prefix answers the question a memory tool cannot: which family of keys is growing, and whether anybody gave it a TTL.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Analyze. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Keys with no namespace
Keys that cannot be counted, found or expired as a group
alpha beta gamma delta epsilon zeta eta theta iota kappa session:1
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Using KEYS * to get the list
It blocks the server for the whole scan, which on a large keyspace is a visible outage.
Instead:Use redis-cli --scan.
Counting keys by summing SCAN batch sizes
SCAN can return the same key more than once, so the sum overcounts.
Instead:Deduplicate, or use DBSIZE for a count.
Assuming a big prefix means a memory problem
This counts keys, not bytes. A small family of large values can use far more memory.
Instead:Cross-check with --memkeys.
Treating one scan as a census
It is a sample spread over the time the scan took, on one node.
Instead:Repeat it, and scan every node on a cluster.
What a prefix breakdown tells you that a memory tool does not
MEMORY STATS says how much is used. --bigkeys names the single largest key. Neither says which of your key families is the one growing without bound.
The dominant prefix is usually the one with no TTL
A family that is most of the keyspace is where growth and memory will come from, and in practice it is the one nobody set an expiry on. TTL on a sample key answers it in one command: -1 means no expiry.
Use SCAN, never KEYS
KEYS returns everything in a single blocking operation, so on a large keyspace it stops the server for the entire scan. SCAN spreads the same work across many short calls, which is why it is safe against a live instance. redis-cli --scan does the loop for you.
A SCAN sample can contain duplicates
SCAN guarantees that a key present throughout is returned at least once, not exactly once. Keys added or removed during the iteration may or may not appear. So counts from a scan are approximate, and code that processes each key must tolerate seeing one twice.
Keys without a namespace cannot be managed as a group
A shared prefix is what lets you count, find or expire a family of keys together. Keys with no separator can only ever be handled one at a time, which stops being viable at any real scale.
What this cannot see
Key names only. It says nothing about the size of the values behind them, so a small family of large values will look unimportant here. Combine it with --memkeys for that.
Related redis tools
Redis Keyspace Notification Flags Why your events never arrive Redis Memory Calculator The encoding decides, not the data Redis Key Count to Memory The fixed cost per key Redis Key Name Validator Legal is not the same as workable Redis INFO Analyzer The numbers INFO does not print Redis SLOWLOG Analyzer What blocked everyone else
All 53 redis tools