A COUNT that will stall the server
Each call is one operation on the single thread, so a huge COUNT is a pause
keyspace-size: 10000000 count: 50000
Redis SCAN Iteration Planner
Plan a SCAN loop. Two things about it are routinely assumed and wrong: COUNT is a hint rather than a page size, and the same key can be returned more than once in a single iteration.
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 Plan. 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.
Scanning a cluster
SCAN answers for one node, not for the cluster
keyspace-size: 5000000 count: 500 cluster: yes
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Counting keys by summing SCAN batch lengths
SCAN can return the same key more than once, so the total overcounts.
Instead:Deduplicate on the client, or use DBSIZE.
Stopping when a batch comes back empty
An empty batch with a non-zero cursor is normal, especially with MATCH.
Instead:Stop only when the returned cursor is 0.
Raising COUNT to make a selective MATCH cheaper for the server
It does make each call more productive, but it also makes each call longer, and MATCH never reduces the work done.
Instead:Balance it; a few hundred is usually right.
Scanning one node of a cluster
You see only the slots that node owns.
Instead:Iterate every primary and combine.
The guarantees SCAN gives, and the ones it does not
SCAN is the safe way to walk a keyspace, and its contract is weaker than most code assumes.
A key can be returned more than once
The guarantee is that a key present for the whole iteration is returned at least once, and that a key absent throughout is never returned. Keys added or removed during the scan may or may not appear, and any key may appear repeatedly. Code that counts by summing batch sizes overcounts, and code that acts on each key must be safe to run twice.
COUNT is a hint about work, not a page size
The server uses it to decide how much to do per call and may return more keys, fewer, or none at all while still returning a non-zero cursor. An empty batch does not mean the end. The iteration is finished when the RETURNED cursor is 0, and nothing else.
MATCH filters after the work is done
The pattern does not make the scan cheaper. The server still walks COUNT keys and then discards those that do not match, so a selective pattern over a large keyspace produces many empty batches while paying full cost for each. Raise COUNT when the pattern is selective.
A large COUNT is a latency spike
Each call is a single operation on the one thread. A large COUNT trades round trips for a longer pause per call, and past a few thousand that pause is measurable by every other client. A few hundred is the usual working range.
On a cluster, SCAN covers one node
Each node has its own cursor space and its own slots. Scanning one node and treating the result as the keyspace silently sees a fraction of it. Every primary has to be iterated separately.
Related redis tools
Redis Glob Pattern Tester Redis globs are not shell globs Redis Key Count to Memory The fixed cost per key Redis Hash Slot Calculator Which of the 16,384 slots does this key land in? Redis Hash Tag Tester Will these keys survive a multi-key command? Redis RESP Protocol Decoder Read what the server actually sent Redis RESP2 vs RESP3 Reply Decoder What the same reply looks like on each protocol
All 53 redis tools