Performance Optimization and Player Limits
Recommended player limits, resource estimates per shard, and steps to diagnose and fix common performance issues.
Resource Usage Baseline
Understanding the baseline resource consumption of a DST server helps you size your node correctly and set appropriate player limits.
| Configuration | RAM | CPU (idle) | CPU (active) |
|---|---|---|---|
| Master only, 16 players | ~300–400 MB | ~5% | ~5–8% per player |
| Master + Caves, 16 players | ~600–800 MB | ~15–20% | ~5–8% per player + caves overhead |
| Master + Caves, 24 players | ~1–1.2 GB | ~25–35% | Higher |
| Master + Caves, 32 players | ~1.5–2 GB+ | ~40–55% | Not recommended |
For a 32-player server with Caves, plan for approximately 10 GB total system RAM across your node if other services are also running.
Recommended Player Limits
- Master only: 16–32 players, depending on node resources and mod count
- Master + Caves: 16–24 players recommended; 32 is the hard cap but will degrade experience significantly
- High-mod servers (15+ mods): Reduce player limits by 20–30%
Set max_players in cluster.ini under [NETWORK]:
[NETWORK]
max_players = 20
CPU Scaling
CPU usage is not evenly distributed. Specific in-game events cause spikes:
- Player joining or spawning
- Large events (meteor showers, hound waves, boss fights)
- Night cycle transitions (all players potentially doing something simultaneously)
- Chunk loading when players explore new areas of the map
Plan for headroom of at least 30% above average CPU to handle these spikes without inducing lag.
Mod Performance Impact
Mods are the most common cause of unexpected performance degradation on otherwise adequately resourced servers.
Best practices:
- Keep active mods under 20
- Avoid mods that run code every game tick (check mod descriptions for mentions of per-tick hooks)
- Profile with and without mods to confirm a mod is the source of lag
- Remove or replace mods that have not been updated in over a year — they may be using deprecated APIs that increase overhead
World Age and Performance
As worlds age (500+ days), the save file grows and chunk count increases. This manifests as:
- Longer startup time as the world loads
- Periodic stutters as old chunks are accessed
- Higher base CPU usage due to larger simulation state
If a world is very old and performance has degraded significantly, a world wipe and regeneration often restores previous performance. Preserve player characters by using the in-game "regenerate world" option if available, rather than deleting save folders directly.
pause_when_empty
If your server is not always occupied, enable pause when empty to avoid wasting resources on an idle simulation:
[NETWORK]
pause_when_empty = true
This pauses the game tick when no players are connected, reducing CPU to near zero during off hours.
Memory Pressure and Swap
DST's Lua VM does not recover memory efficiently. On long-running servers, RAM usage creeps upward. If your node is swap-heavy, the server will start producing lag even at lower player counts. Schedule a weekly restart via your panel to reclaim memory if you observe this pattern.
A restart during off-peak hours takes under two minutes and keeps the server consistently responsive.
Diagnosing Lag
When players report lag, check in order:
- Panel CPU/RAM graphs — Is the node saturated? If yes, reduce player limits or disable mods.
- Caves overhead — Is Caves running and contributing excessive CPU? Check if disabling Caves resolves the issue.
- Mod count — Disable all mods and test. Re-enable one at a time.
- World age — Is the world over 500 days? Consider a wipe.
- Network — Verify that the node has low latency to your player base; DST is sensitive to packet loss on UDP.