Hardware for a game server: clock speed over core count
A game server simulates the world in a single thread: the whole tick — physics, AI, events — runs on one core. What decides performance is the clock speed of that core and how steadily it is held, not the total number of cores. Cores matter when you run several instances side by side, because each gets its own. Size memory by instance count and take NVMe for map loading and saves.
- One world equals one core. Eight cores will not speed up a single tick, but they will hold eight worlds.
- The tick budget is 50 ms at 20 tps and about 15 ms at 64 tps. Going over budget is what players feel as stutter.
- Memory: 4-8 GB per Minecraft Java world, 1-2 GB per Source instance, 8-16 GB for a large Rust world.
- Game traffic is many small UDP packets, not gigabits. The uplink limit you hit is packets per second, not width.
- A governor left on powersave gives a floating clock and an unstable tick; set performance.
Why clock speed beats core count
The simulation loop in most engines is sequential: the server computes world state, sends out snapshots and sleeps until the next tick. That loop cannot be parallelised, because each step depends on the result of the previous one. A higher-clocked core walks the same loop in less time, which is a direct win visible on a tick-time graph.
Multiple cores do something different: they provide isolation. Three Minecraft worlds on three cores do not interfere with each other, while one world on twelve cores loads a single core and idles the rest. The general logic of matching a CPU to a workload is covered in the article on choosing a server processor.
The practical conclusion: for one heavy world with a hundred players, a plan with an E3-1270v6 can match a dual-socket machine, while for ten smaller worlds the E5-2680v4 with more threads wins.
How much memory and disk you need
| Profile | RAM per instance | Also critical | Matching plan |
|---|---|---|---|
| Minecraft Java, 20-40 players, modpack | 6-8 GB | Core clock, NVMe for chunk generation | Start DE / Start FR |
| Source games, 3-5 instances | 1-2 GB | Steady tickrate, low jitter | Start DE / Start US |
| Rust, medium world | 10-16 GB | Memory and world load speed | Pro DE / Pro FR |
| 10 or more worlds at once | 32-64 GB total | Thread count, RAID10 for saves | Enterprise US |
Starting a world reads hundreds of megabytes from disk, and autosave writes them back under load: on a SATA SSD that is a visible tick drop, on NVMe it disappears. The Pro and Enterprise plans ship NVMe in RAID1 and RAID10; the configurations are listed on the dedicated servers page.
Uplink, latency and location
A game server sends every player a snapshot on every tick. Bandwidth consumption stays modest, but the packet rate gets high, and it is those packets the network stack has to process. An unmetered 100 Mbit/s uplink in Germany comfortably holds dozens of game slots, though the traffic allowance is worth checking if you also distribute modpacks: see the article on the server uplink and traffic limits.
Latency to your players outweighs every other hardware decision. Pick the facility by audience geography and verify it with measurements: the procedure is in the article on choosing a server location.
Tuning Linux for a steady tick
Three things do more than any in-game config "optimization": a pinned clock, larger network buffers and process priority.
# Debian/Ubuntu: pin the clock at maximum
apt-get install -y linux-cpupower
cpupower frequency-set -g performance
# RHEL/AlmaLinux/Rocky
dnf install -y kernel-tools tuned
tuned-adm profile latency-performance
# verify the clock is actually held there
grep MHz /proc/cpuinfo | head -4
cpupower frequency-info | grep -E 'governor|current'# network buffers for many small UDP packets
cat << 'EOF' > /etc/sysctl.d/90-game.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 5000
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
EOF
sysctl --system 2>&1 | grep -E 'rmem_max|backlog'
# priority for the world process and its disk access
systemctl set-property game@world1.service CPUWeight=900 IOWeight=900After the changes, watch the maximum tick time over a minute rather than the average: stutter lives in the peaks. If the peaks line up with autosave, stagger the save schedules of different worlds.
Game ports live on UDP, and L7 filtering does not cover them: what works against a flood aimed at a game port is L3/L4 protection at the uplink. In Germany and the USA it is enabled on every plan, in France Anti-DDoS Arbor does the job; details are in the article on DDoS protection for a dedicated server. The second common mistake is leaving the governor on powersave and then hunting for the cause of stutter inside the game config. Check it this way: run load, sample grep MHz /proc/cpuinfo several times in a row and confirm the clock does not drop between samples.
Key takeaways
- One world runs on one core: clock speed is a direct win on tick time, core count only buys you more worlds.
- Plan memory per instance: 6-8 GB for a Minecraft modpack, 1-2 GB per Source instance, 10-16 GB for a Rust world.
- NVMe removes the tick drops caused by autosave and map generation; SATA SSD leaves them in.
- The uplink is spent on packets rather than gigabits, and latency to the audience matters more than width.
- Performance governor, larger UDP buffers and process priority beat editing the game config.