Element counts, not memory
A two million item list, and why that number does not answer a memory question
Biggest list found '"queue:jobs"' has 2000000 items
Redis Bigkeys Output Analyzer
Paste the summary from redis-cli --bigkeys or --memkeys. The distinction decides everything: --bigkeys counts elements, --memkeys measures memory, and the largest key under one is often not the largest under the other.
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.
A large string
Every read copies the whole value into a client output buffer
Biggest string found '"cache:page"' has 20971520 bytes
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Chasing the biggest --bigkeys key for a memory problem
It reports element count for collections. A key with fewer, larger elements can use much more memory.
Instead:Run --memkeys, or MEMORY USAGE on the specific keys.
Deleting a huge collection with DEL
DEL is O(N) for collections and blocks the single thread for the whole free.
Instead:Use UNLINK, which frees it on a background thread.
Running it against the primary during peak
It walks the entire keyspace issuing commands per key, which is sustained extra load.
Instead:Run it against a replica.
Treating the summary as a complete picture
It names only the largest key per type. Many medium keys can matter more in total and never appear.
Instead:Use a prefix breakdown for aggregate shape.
Why the biggest key is not the biggest problem
These two tools look interchangeable and answer different questions. Choosing the wrong one sends you after the wrong key.
--bigkeys counts elements, --memkeys measures bytes
For collections, --bigkeys reports how many members a key has. A list of 100,000 small integers can occupy less memory than a list of 1,000 long strings, so ranking by element count does not rank by memory. If the question is 'what is using the RAM', --memkeys is the tool.
A large collection is a latency problem before it is a memory problem
Redis executes on one thread, so any O(N) command over a large collection blocks every other client for the duration. DEL is itself O(N) for collections, which is why deleting a huge key can cause a visible stall. UNLINK frees it on a background thread instead.
On a cluster, one key cannot be split
A key lives entirely in one slot, which lives on one node. A single enormous collection therefore caps how evenly the data can shard, and no amount of rebalancing helps, because the unit of movement is the slot and the key cannot leave it.
The scan itself costs something
Both modes walk the whole keyspace with SCAN and issue a type and size command per key. They do not block, but on a large keyspace they add sustained load, and the result is spread over however long the run took rather than being a single consistent moment.
What this cannot see
Only the largest key per type is in the summary, so a thousand keys of moderate size, which together matter more, do not appear at all. Use the keyspace prefix breakdown for that shape.
Related redis tools
Redis Glob Pattern Tester Redis globs are not shell globs Redis INFO Analyzer The numbers INFO does not print Redis SLOWLOG Analyzer What blocked everyone else Redis MEMORY STATS Analyzer Which number actually matters Redis CLIENT LIST Analyzer Find the connection hurting you Redis LATENCY Report Analyzer An empty report may mean nothing was recorded
All 53 redis tools