A large dataset
400 GB across 64 GB nodes with one replica each
dataset: 400gb node-memory: 64gb replicas: 1
Give the dataset size and the memory per node. The result assumes only part of each node is usable for data, because replication buffers, client buffers and the fork a save performs all live outside maxmemory.
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.
400 GB across 64 GB nodes with one replica each
dataset: 400gb node-memory: 64gb replicas: 1
The same cluster with no failover, which is a cluster that cannot survive a node loss
dataset: 400gb node-memory: 64gb replicas: 0
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Replication buffers, client output buffers and the copy-on-write during a BGSAVE all sit outside it. The process is then OOM killed during a save.
Instead:60 to 70% of the machine is the usual starting point.
Failover needs a majority of primaries to agree a node is down, which is impossible below three.
Instead:Three primaries minimum, even when one would hold the data.
Slots are the unit of assignment, not of work. A hash tag concentrating a large tenant puts all of it on one node.
Instead:Check per-node memory, not slot counts.