A hash under the threshold
Twenty fields per key, which stays in the compact encoding
type: hash keys: 1000000 fields: 20 field-bytes: 12 value-bytes: 32
Describe the keys and get a memory range, with the encoding that decides it named. Every figure is a range, because the exact number depends on allocator behaviour and on data this cannot see.
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 Calculate. 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.
Twenty fields per key, which stays in the compact encoding
type: hash keys: 1000000 fields: 20 field-bytes: 12 value-bytes: 32
The same keys with 200 fields, which switches to a hashtable
type: hash keys: 1000000 fields: 200 field-bytes: 12 value-bytes: 32
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Key names, the dict entry, the robj and allocator rounding are frequently more than the values, and none of it appears in a back-of-envelope calculation.
Instead:Include the per-key overhead. For small values it dominates.
Fragmentation, copy-on-write during a save and client buffers all sit outside this model.
Instead:Load a sample and read used_memory. MEMORY USAGE on a real key is the ground truth.
7.0 replaced ziplist with listpack and 7.2 added listpack for sets. The same data occupies different amounts on different versions.
Instead:Set the version. It changes the encoding and therefore the answer.