Why your Rust server tanks on wipe day (and what actually fixes it)

Wipe day is the worst-case load profile in Rust: peak concurrency, peak entity creation and peak network churn, all at once. When a server falls over, it is almost always one of four causes.

1. Single-thread ceiling

Rust's main loop is largely single-threaded. A 32-core server part with a 2.4 GHz base clock will lose badly to an 8-core desktop part boosting to 5.7 GHz. If your host advertises core counts and never mentions clocks, that tells you what they optimised for.

Fix: high-clock hardware. This is the one you cannot solve in config.

2. Oversold nodes

The most common cause and the hardest to prove from inside the container. Your server looks fine — CPU usage is moderate, memory is fine — and yet the tick rate is unstable, because you are being descheduled by neighbours. Look for CPU steal time: if it is consistently above a few percent, you are sharing with someone loud.

Fix: a host that caps allocation below real capacity. Ask what percentage they fill a node to. A host that cannot answer is overselling.

3. Entity count

Every deployable, every foundation, every sleeping bag is an entity that gets simulated and networked. A server three weeks into a wipe with no decay enforcement can be carrying several times the entity count it started with.

Fix: tune decay, run entity cleanup on your restart schedule, and enforce building limits. This is config work, not hardware.

4. Plugin overhead

Plugins run on the same main thread. One badly written plugin doing a synchronous database call per player per tick will cost you more than fifty well-written ones.

Fix: profile with the Oxide plugin timing tools, sort by total time, and be ruthless about the top of that list.

The diagnostic order

Check steal time first — it tells you whether the problem is yours or your host's. Then entity count, then plugin timings, then hardware. Upgrading the plan is the last thing to try, not the first, and any host who suggests it first is guessing.