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
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.
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.
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.
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.
Three quarters of the sample under one prefix, which is where growth comes from
session:a session:b session:c cache:x
Keys that cannot be counted, found or expired as a group
alpha beta gamma delta epsilon zeta eta theta iota kappa session:1
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It blocks the server for the whole scan, which on a large keyspace is a visible outage.
Instead:Use redis-cli --scan.
SCAN can return the same key more than once, so the sum overcounts.
Instead:Deduplicate, or use DBSIZE for a count.
This counts keys, not bytes. A small family of large values can use far more memory.
Instead:Cross-check with --memkeys.
It is a sample spread over the time the scan took, on one node.
Instead:Repeat it, and scan every node on a cluster.
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.
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.
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.
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.
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.
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.