Halloween at Nexthosting: 10% off game servers with the code – until November 1
Plan server resources: measure a baseline, size RAM and storage with a 1.5–2x buffer, pick CPUs by single-core clock speed, use NVMe for critical paths.
When planning server resources, size from the workload: generous RAM and storage with a buffer (factor 1.5 to 2), and CPU by single-core clock speed rather than core count. Key tuning levers are parameters such as OneSync for FiveM, simulation and view distance for Minecraft, and NVMe storage as the basis for latency-critical paths. The following sections show the calculation method, rules of thumb per workload, and concrete tuning values for day-to-day operation.
In short:
- For reliable sizing of server resources, a real baseline, measured from the current CPU, RAM, and I/O load, is essential.
- The RAM and storage buffer should be 1.5 to 2 times the baseline to handle load spikes and future growth.
- Game servers benefit from a high single-core clock speed and NVMe storage, while databases need the hot set entirely in RAM and NVMe in RAID 10.
- On game servers, load can be reduced mainly through targeted configuration settings such as distance parameters and entity culling.
- For pure game traffic, a 1 Gbit/s internet connection is usually enough; internal bandwidth matters more for replication and backups.
The method follows three steps: measure the baseline, build in a buffer, plan for growth. Without a baseline, you are planning blind, because every buffer calculation requires a real number.
For network bandwidth, a simple conversion applies: one terabyte of traffic per month corresponds to roughly 3 Mbit/s of sustained load, and a 1 Gbit/s connection can theoretically move about 330 terabytes per month. This rule of thumb also gives you the basis for restore times, which follow in the section on network and backup.
Every workload has its own logic, and anyone who sizes all servers using the same scheme wastes money in the wrong place.
On game servers, the biggest lever is rarely more hardware but the configuration itself. With OneSync, FiveM uses a system of routing buckets and culling that limits the number of entities synchronized at the same time. The native command SetEntityDistanceCullingRadius reduces entity streaming in a targeted way and thus directly lowers server load, as the OneSync documentation describes. For very large FiveM communities, it is also worth offloading voice services such as separate Mumble instances instead of running everything through one process.
In Minecraft, two parameters directly affect CPU and I/O load: simulation-distance and view-distance in the server.properties. Both default to 10 chunks. If you have lag problems, reduce the simulation distance first, since it controls entity calculations and redstone ticks, while the view distance mainly affects visibility range and network transfer.
Pro tip: Change only one parameter per test run. If you adjust simulation distance and entity pool at the same time, you cannot say later which value brought the improvement.
The calculation from the baseline section can be reused directly: 1 TB of traffic per month corresponds to roughly 3 Mbit/s of sustained load, and a 1 Gbit/s port comes to about 330 TB per month. For pure player traffic on a mid-sized FiveM or Minecraft server, that is usually more than enough.
A 1 Gbit/s connection can theoretically handle about 330 TB of data volume per month.
It gets more interesting with so-called east-west traffic, meaning internal communication between servers for replication, backups, and restores. Here, internal bandwidth often matters more than the public connection, because restore windows are business-critical and nobody wants to wait hours for a backup to be restored.
An example makes the difference clear:
For latency-sensitive paths such as database replication or live restores, NVMe storage is almost always the better choice compared to SATA SSDs or conventional hard drives, because random I/O accesses are processed significantly faster there.
Monitoring decides whether a decision is based on gut feeling or on data. You should keep an eye on five values at all times:
When deciding between scale-up and scale-out, a simple rule helps: stateful services such as game servers or databases usually benefit from scale-up, meaning more performance on the same instance, while stateless services distribute well across multiple instances. Test larger changes on a single instance first, before rolling them out across the entire infrastructure.
Three rough templates help you get started: a small Minecraft server for up to about 20 players often gets by with 6 to 8 GB of RAM and NVMe storage, a mid-sized Rust or Valheim server needs closer to 16 GB of RAM because of world size, and a regional FiveM instance benefits more from a high single-core clock speed than from additional cores.
Most mistakes happen because operators think in slots instead of hardware parameters. Slots are a price tag, not a technical quantity, and anyone who buys only by player count completely ignores single-core load, the RAM hot set, and I/O patterns. Providers with an NVMe foundation and flexibly scalable VPS and dedicated options make this iterative approach practical, because resources can be adjusted afterward without having to rebuild the entire infrastructure.
— Erik
The method in this article only works if the hardware keeps up: NVMe storage, sufficient single-core performance, and a buffer for growth. Nexthosting offers game servers for Minecraft, FiveM, Garry’s Mod, and other titles, as well as flexible VPS servers with NVMe SSD and DDoS protection included at no extra charge. If you have measured your baseline and are now looking for a suitable starting configuration, the game server category page offers plans for different games at different prices. For projects with higher RAM or CPU requirements, it is worth looking at larger VPS tiers if your own baseline is above the base plans. Support helps with setting up tuning parameters such as simulation distance or OneSync configuration. Look at your current setup, compare it with your calculated baseline, and switch straight to the matching tier if needed.
For a deeper dive into game server tuning, the OneSync documentation provides all the routing bucket details, the Minecraft Wiki page on server.properties explains every configuration parameter, and the sizing guide for dedicated servers substantiates the baseline-buffer method. In addition, the Infrawire article on dedicated gaming servers provides background on the single-core priority.
It depends on the game, but as a rule of thumb, plan on 8 to 16 GB per instance group for titles like Minecraft or Rust. More important than the absolute number is a buffer of 1.5 to 2× over the measured baseline.
In Minecraft, view distance controls how far players can see and how many chunks are sent to the client. Simulation distance determines how far redstone, mobs, and other calculations stay active, and it has a greater effect on CPU load, as the official configuration page describes.
Stateful services such as game servers or databases usually benefit from scale-up, meaning more performance on the same instance, because they are hard to distribute. Stateless components, on the other hand, can be split well across multiple instances in a scale-out model.
By the rule of thumb, 4 TB per month equals roughly 12 Mbit/s of sustained load, far below the capacity of a 1 Gbit/s connection. For internal replication and restores, higher internal bandwidth is still worthwhile, regardless of public traffic.
Prices start at €7.99 per month for Minecraft and go up to €17.99 per month for Rust, each visible on the game server category page. VPS plans with more control over resources start at €6.49 per month on the VPS overview.