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
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.
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.
A two million item list, and why that number does not answer a memory question
Biggest list found '"queue:jobs"' has 2000000 items
Every read copies the whole value into a client output buffer
Biggest string found '"cache:page"' has 20971520 bytes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
It walks the entire keyspace issuing commands per key, which is sustained extra load.
Instead:Run it against a replica.
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.
These two tools look interchangeable and answer different questions. Choosing the wrong one sends you after the wrong key.
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.
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.
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.
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.
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.