Rust Wipe-Day Hardware Sizing: 400-Slot Node CPU, RAM and Save-IO Budgets

Rust is not a steady-state workload. For roughly 22 hours out of every 168 (assuming a Thursday monthly wipe), the server does almost nothing. Then, within a 90-minute window, 400 players simultaneously connect, spawn into a freshly generated world, and every one of them triggers a wave of entity creation, terrain streaming and save writes. Capacity planning for Rust is really the art of sizing for that 90-minute window — not for the quiet Tuesday afternoon.

What actually spikes on wipe day

Three resources peak at different times and each has its own ceiling. Getting the order wrong is why operators buy 256 GB of RAM and still watch the server hitch during world generation.

• CPU (0-25 minutes): world generation is the single worst CPU event in the Rust lifecycle. Terrain, biome and monument generation plus the initial entity spawn uses every core you give it, and then the process settles back to a few threads. A 4-core node generates a 4500×4500 map in roughly 6-9 minutes; a 16-core node does the same map in 2-3 minutes because generation is genuinely parallel. This is the one workload where more cores beats more clocks.
• RAM (25-90 minutes): entity count drives resident memory. A 400-slot server with ~6000 player-built entities, ~2000 deployables and full animal/NPC population commonly floats between 14 and 22 GB RSS. Budget 48 GB minimum for a 400-slot server so the page cache has room to absorb save writes, and 64 GB if you run a modded stack with additional plugins.
• Disk write (continuous, spiked at wipe): Rust writes the full world save on a timer and again on shutdown. A 4500×4500 map with heavy building is 500-900 MB per save, and it is written as one large sequential burst. On SATA SSD this is a 6-10 second stall; on NVMe it is 1-2 seconds.

The 400-slot reference build

These numbers come from a monthly-wipe pattern where the node is dedicated to Rust and nothing else. Treat them as a floor, not a target.

• CPU: AMD Ryzen 9 7950X or EPYC 9354 — you want 4.5-5.0 GHz boost on the game loop thread and 16+ physical cores for generation. Rust’s main thread is the bottleneck at ~400 slots; sub-4.0 GHz parts show a GSP (game server performance) number that climbs steadily after 300 players.
• RAM: 64 GB DDR5-5600 ECC. Rust leaks slowly across a wipe cycle, so a server that starts at 12 GB RSS will sit near 20 GB by day 25. ECC is not paranoia at this footprint — a single flipped bit in an entity index crashes the whole world.
• Storage: 1 TB NVMe with at least 1 DWPD rated endurance. Rust’s per-wipe write volume for a large map runs 1.5-3 TB across a month when you count periodic autosaves, log rotation and SteamCMD update churn. A 0.3 DWPD consumer drive will be at 40% of its TBW inside a year.
• Network: 1 Gbps minimum, 10 Gbps if you run a cluster. Per-player upstream averages 15-35 KB/s but bursts hard during base raids.

Save-IO tuning that removes the wipe-day stall

The most common cause of “server froze for 8 seconds” on wipe day is the autosave colliding with the player connect storm. Two changes fix almost all of it.

server.saveinterval 300
server.savebackupinterval 900
server.savecachesize 1024
server.maximumqueryport 28016

Raising saveinterval from the default 60 to 300 seconds cuts autosave frequency by 5x during the critical first hour. Set savecachesize to 1024 MB so the save buffer holds in RAM rather than streaming to disk in small chunks. On the OS side, mount the server directory on XFS rather than ext4 — Rust’s large single-file writes benefit measurably from XFS delayed allocation.

Also place server.identity on its own NVMe namespace if you host multiple Rust instances. Putting two 400-slot servers on one SATA SSD guarantees that both stall whenever either saves. Our dedicated server comparison table lists which chassis allow independent NVMe namespace assignment.

Scheduling the wipe to protect hardware

Force wipe at a fixed UTC hour and stagger your cluster maps by 20 minutes each. If you run three linked servers and let them all regenerate at once, you triple the generation CPU load on shared storage and turn a 3-minute generation into a 12-minute one. A staggered pattern — 18:00, 18:20, 18:40 UTC — keeps disk queue depth under control and lets the first map finish populating before the second starts thrashing the same NVMe controller.

For a second node or failover host, keep a pre-generated world image on standby. Restoring a generated 4500×4500 map takes about 40 seconds from NVMe versus 3-9 minutes to generate from scratch, and it removes the CPU spike entirely from your recovery path. If you are still deciding between a single fat node and two smaller ones, compare bare-metal specs side by side before you commit — the generation-parallelism argument usually favours fewer, wider cores.