Matching Game Server Hardware to Player Count: CPU, RAM and Storage Decision Tables

Most over-provisioned game servers are bought to solve the wrong problem. A community that drops ticks at 90 players often upgrades from 8 to 16 cores, sees no change, and concludes the game is badly optimised. In practice the bottleneck was one thread at 4.1 GHz, or a save stall on a consumer NVMe, or 30 mods each holding their own object graph in a heap that was sized for vanilla. The tables below size hardware against the three axes that actually cap player count, with the decision rules spelled out so the first order is the right one.

Identify the Bottleneck Before You Buy

Run the node at your intended player count for a full session and read three signals. If tick rate falls while total CPU sits below 50%, you are single-thread bound and more cores will not help. If resident memory climbs toward the limit and the kernel starts reclaiming, you are capacity bound on RAM. If tick time spikes only during autosave windows, you are storage-latency bound. Each maps to a different purchase.

# Thread-level view: is one core pegged?
pidstat -t -p $(pgrep -f server.jar) 5 3

# Memory pressure and page reclaim
vmstat 5 10 | awk '{print $1,$2,$6,$7}'   # free, si, so

# Save-stall detection: watch write latency, not throughput
iostat -x 5 | egrep 'Device|nvme' | awk '{print $1,$2,$NF}'

Decision Table 1: Players to CPU

The clock column is the one to defend in negotiations. A 16-core 3.2 GHz EPYC loses to an 8-core 4.6 GHz part on tick rate for every Minecraft, Valheim, and ARK workload in the table, because the simulation loop is serial. Ask for the sustained all-core turbo figure, not the marketing boost number, and ask what happens under AVX-512 load — some Xeons drop to 2.4 GHz on heavy vector workloads, which includes parts of some survival servers’ pathfinding.

Decision Table 2: Players to RAM

Per-player heuristics help sanity-check the table: budget roughly 0.4-0.6 GB per player for vanilla Minecraft and 1.5-2.5 GB for a 180-mod pack, because each mod retains its own entity and recipe graph regardless of population. For ARK the map itself dominates: a cluster instance holds the entire terrain and dino population resident even with three players online. That is why the last row is per map, not per player — five-map clusters need 30-100 GB before anyone connects.

One JVM detail that fools people: heap size is not the same as resident memory. Set -Xmx no higher than about 75% of node RAM and leave room for off-heap buffers, GC structures, and the page cache. Allocating the full node to -Xmx produces swap stalls under GC pressure, which look exactly like a CPU bottleneck.

Decision Table 3: Players to Storage

Power-loss protection (PLP) on the drives matters more than raw throughput for survival servers. Without it, the drive’s write cache can be lost mid-save after a power event, and the result is a world file that loads with half its structures missing. For Rust and 7 Days to Die specifically, map save size grows with player-built structures — a fresh map is tens of megabytes, a month-old wiped-ready map is several hundred — so sequential throughput starts to matter by week three.

Combining the Axes Into One Purchase

Build the specification from the strictest axis, then check the other two are not further constrained. A 100-player modded Minecraft node needs 12 vCPU at 4.5 GHz, 64 GB, and 400k IOPS NVMe. Buying 24 slower cores with 128 GB and SATA SSD fails on all three counts while looking bigger on a spec sheet. The rule: pick CPU clock from Table 1, confirm RAM from Table 2, then confirm storage from Table 3, and reject any quote that trades clock for cores.

Validate Before You Commit to a Term

Tables are a starting point. Load test with real players on a real world, incrementing in steps of 20, and record MSPT or tick rate at each step. A shard sitting at 60% CPU with falling tick rate is already full; one at 90% CPU with flat tick rate is not. Run at least one six-hour session to catch memory growth from entity accumulation, and check whether the save window still completes in under 15% of your tick budget at peak population.

If you cannot run the test on a demo instance, ask the provider for a short-term test slot — most will give 24-48 hours on the tier above your target. That test is worth more than any benchmark chart. When you are ready to compare configurations, the dedicated server hosting options page lists clock speeds and storage classes side by side, and hosting reviews on bare metal and game nodes show which providers actually deliver the sustained turbo figure they advertise.

The Order of Spending

Rank upgrades by effect on the bottleneck: sustained single-thread clock first, then RAM headroom to the 25% mark, then NVMe with power-loss protection, then core count for auxiliary services. Only after all four are satisfied does sharding become cheaper than scaling up. Most communities spend in the reverse order and pay twice for the same lesson.