Rust does not behave like a steady-state game server. Across a 168-hour wipe cycle, roughly 22 hours carry almost no load, and then a single 90-minute window decides whether your community stays. When the monthly wipe fires, hundreds of players connect at once, spawn into a freshly generated procgen map, and trigger a simultaneous wave of entity creation, terrain streaming, and save writes. A node sized for the average case collapses at exactly the moment it matters. This guide gives you the CPU, RAM, and disk budgets to survive wipe day with headroom to spare.
What Actually Happens in the First 90 Minutes
Wipe day is a serialisation storm, not a player-count problem. Three workloads overlap:
- World generation. Procgen for a 4500-map costs a burst of single-thread CPU. This is clock-bound, not core-bound.
- Entity and base spawn. Every player builds a starter base within the first hour. Entity count climbs from ~2,000 to 40,000+ on a 400-slot server inside that window.
- Save writes. The
.savfile grows from 30 MB to 400-700 MB in one session. Rust writes atomically, so each save is a full rewrite under a lock.
The failure pattern is consistent: players feel a stutter at 45 minutes, then a 6-12 second freeze at 70 minutes when the entity count crosses the point where a single-threaded tick no longer fits the 33 ms (30 Hz) budget.
CPU Budget for a 400-Slot Node
Rust’s main tick is effectively single-threaded. You want the highest sustained single-core clock you can buy — 5.0 GHz+ boost, and critically a part that holds 4.5 GHz+ on all-core without thermal throttling. Cores matter, but for a different reason: Rust parallelises physics, save I/O, and networking across worker threads.
| Slots | Recommended CPU | Single-thread floor | Physical cores |
|---|---|---|---|
| 50-100 | Ryzen 7 7700 / i7-14700K | 4.8 GHz sustained | 8 |
| 200 | Ryzen 9 7900X / Xeon E-2488 | 5.0 GHz sustained | 12 |
| 400 | Ryzen 9 7950X3D / EPYC 4584PX | 5.3 GHz boost, 4.6 all-core | 16 |
| 400+ clustered | Two EPYC 4584PX nodes | 5.3 GHz per node | 16 x2 |
Avoid high-core-count, low-clock parts. A 64-core EPYC at 3.2 GHz will lose to a 16-core Ryzen at 5.3 GHz on wipe day every time, because the tick cannot spread across cores. When you compare specs on dedicated server hardware options, prioritise clock over core count first.
RAM: The 400-Slot Reality
Empty-server baseline memory is 2-3 GB. Then it scales with entity count:
- 100 slots, mid-wipe: 6-8 GB
- 200 slots, populated: 12-16 GB
- 400 slots, late-wipe with big bases: 24-32 GB
Wipe day itself is not the memory peak — late-wipe is, when procedural bases and their deployables are still loaded. Provision 32 GB for 400 slots and never rely on swap. Rust will happily allocate past physical memory and then hitch every tick while the kernel pages.
Save I/O and the Atomic Write Problem
A 600 MB save written atomically every 10 minutes is a sustained write workload, and it spikes hard during wipe. NVMe is not optional here. Budget:
- Endurance: a populated 400-slot server writes 30-60 TB/year of save data. Pick a drive with 1 DWPD or higher in the enterprise class.
- Latency: save freeze duration is bounded by fsync latency, not throughput. A drive with 120 µs write latency cuts the freeze by 40% versus one at 200 µs.
- Isolation: put the save volume on a separate physical NVMe from the OS and logs so a save burst cannot starve server binaries.
The 2026 Wipe-Day Checklist
- Set the wipe at a fixed low-traffic hour and pre-generate the map before the wipe so procgen cost is off the critical path.
- Raise the save interval to 15 minutes for the first two hours, then tighten back to 5-10 once the world stabilises.
- Cap entity count per base in the config if your community is large; this is the single most effective wipe-day lever.
- Watch single-core utilisation, not total CPU. Total can sit at 30% while one core pins at 100% and the server stutters.
- Keep 20% CPU headroom on wipe day. If you are at 80% at peak, you are one big base away from a freeze.
Correlated Load: The Hidden Wipe-Day Killer
The reason wipe day breaks servers is not raw volume — it is correlation. Every player acts at once, so every subsystem peaks simultaneously. Save writes coincide with procgen, which coincides with entity creation, which coincides with terrain streaming to newly connected clients. On an average Wednesday these workloads are spread across hours; on wipe day they stack into the same 20 minutes.
You cannot de-correlate the players, but you can de-correlate the workloads. Pre-generating the map moves procgen entirely off the critical path. Staggering the first save moves it after the initial connection burst. Throttling the connection queue so clients join in waves spreads terrain streaming over a longer window. Together, these three changes can halve the peak single-core load even without changing hardware.
Monitoring Wipe Day Without Guesswork
Instrument before the wipe, not during it. The four metrics that tell you the whole story are single-core utilisation, save-cloud freeze duration, entity count, and connected-player count, sampled every ten seconds. Plot them together and the shape of your bottleneck is obvious: a freeze that lines up with an entity-count wall means CPU; a freeze that lines up with a save event means disk fsync latency; rising latency without CPU movement means the network path.
Keep the graphs from your last three wipes. The trend tells you when you will need the next upgrade, months before players feel it.
When to Split Into a Cluster
A single 400-slot node is the practical ceiling for one Rust process. Past that, the answer is a cluster: multiple server instances sharing one player base via a proxy, each hosting a subset of the world or a separate game mode. This scales players past the single-node tick limit but requires cross-instance chat, a shared authentication layer, and careful routing. For communities approaching 500+ concurrent players, cluster architecture is the only path that keeps tick time in budget. See the wider game server scaling approach for the sharding and load-balancing patterns that apply across Minecraft, Rust, and ARK.
If you want a node that survives this cycle without manual babysitting, an AMD Ryzen 9 bare-metal server with NVMe storage and a 10 Gbit uplink is the practical baseline for 2026. Size the clock first, the RAM second, and the disk latencies third — in that order, wipe day stops being an emergency.
Leave a Reply
You must be logged in to post a comment.