Server Spec Requirements by Game Genre: Survival vs FPS vs MMO vs Web

A survival server, a competitive FPS server, an MMO shard and a web node stress completely different parts of the same chassis. Buying one spec sheet for all of them produces the familiar failure: 32 cores idling at 8% while a 64-player server stutters every time a distant base loads. The table below sets a per-genre floor, and the reasoning afterwards explains which number moves when the workload changes.

Every figure assumes rented bare metal where the provider publishes the actual CPU model, the memory configuration and the disk model. If the spec sheet says “high frequency Xeon” and nothing else, the numbers below cannot be verified and the comparison is guesswork. Start from the part number, then apply the genre floors.

Survival servers are bound by clock and heap

Valheim, 7 Days to Die, Icarus, Enshrouded and Palworld spend their frame budget on entity simulation and block updates for one loaded region set. The floor is roughly 4.0 GHz sustained all-core with 4.8 GHz boost on the two threads driving world ticks. Below 3.6 GHz sustained, save-and-load cycles stretch past 90 seconds on a 4 GB world.

Memory per instance runs 2.5-4 GB for a ten-player vanilla world and 6-10 GB for a modded twenty-player world, on top of a 15% margin and 3-4 GB for page cache during saves. A 48-slot server at 450 MB per slot needs 21.6 GB of heap, which lands on a 32 GB box once the OS and cache are counted.

Survival tier	Clock floor	RAM per slot	NVMe read IOPS (QD32)	Uplink
10 players vanilla	4.0 GHz	96 MB	60k	20 Mbit/s
24 players modded	4.4 GHz	320 MB	120k	50 Mbit/s
48 players + builds	4.6 GHz	450 MB	200k	100 Mbit/s

Competitive FPS lives inside an 8 ms budget

CS2, Squad and Hell Let Loose run a fixed simulation interval: 15.6 ms at 64 tick, 7.8 ms at 128 tick. That interval includes game logic, network softirq and any disk flush that happens during play. Player counts barely change the per-tick cost; what changes it is the number of active entities and visibility checks.

The practical floor is 4.2 GHz with boost above 4.8 GHz, pinned cores with SMT disabled for the simulation thread, and a NIC with RSS steering interrupts away from that core. A 128-tick server at 20 players can be harder on hardware than a 64-tick server at 40 players, so slot counts are a poor proxy for load. tick-rate hardware selection should always be tested at the target rate, not extrapolated.

MMOs and persistent worlds are write-bound

An MMO shard reuses very little of the survival profile. Inventory changes, trades, mail and auction activity become durable database transactions, and the bottleneck moves to fsync latency and the write path of the storage stack. A 4-core VM with a fast local NVMe and a tuned InnoDB configuration often beats a 32-core box on shared network storage.

Budget 1 dB shard at 500-2000 concurrent players with 8-16 cores, 32-64 GB of ECC RAM, and a database volume with at least 3 DWPD endurance. Keep world data and logs on separate volumes so a log burst during an incident cannot starve the transaction log. This is the genre where ECC memory pays for itself.

Workload	Primary bottleneck	Cores	RAM	Storage priority
Survival	Single-thread clock	4-8	16-32 GB	Save fsync latency
Competitive FPS	Per-tick budget, jitter	4-6	8-16 GB	Minimal, logs only
MMO / persistent	Database write latency	8-16	32-64 GB	Endurance + fsync
High-traffic web	Concurrent requests	8-16	32-64 GB	Random read cache

High-traffic web needs threads and cache, not clock

An nginx plus PHP-FPM plus MySQL stack serving 4,000 requests per second is happiest with many cores, a large page cache and fast random reads. A 3.2 GHz 16-core Xeon Silver will beat a 4.5 GHz 8-core Ryzen here, while losing badly to it on a Valheim world. Thread count and memory bandwidth decide the web case.

Size by concurrent connections rather than monthly visitors. A site with 100,000 daily visitors at a 5% concurrency peak holds about 5,000 active connections; at 30 KB per connection working set, PHP workers and buffers need roughly 1.5 GB before the database is counted. Add a 40% headroom and the memory target becomes visible.

Why the same chassis scores differently

The difference is where time is spent. Survival and FPS workloads push a single thread toward a deadline measured in milliseconds. MMO workloads push durable writes through a storage stack. Web workloads push many short requests through a scheduler. Optimising for one profile actively hurts another: SMT helps web throughput, hurts FPS jitter; huge page caches help web, displace heap for game servers.

That is why hosts who run mixed fleets separate machines by genre. Running a CS2 instance next to a modded Minecraft server on the same 8-core part means the JVM garbage collector’s CPU spikes land inside the FPS tick window. If mixed hosting is unavoidable, pin the FPS server to dedicated cores and cap the JVM heap so it never triggers a full collection.

Reading a provider spec sheet against these floors

Map every advertised field to the table above and mark anything that cannot be mapped. “Enterprise SSD” maps to nothing unless it names TLC versus QLC and a TBW figure. “Up to 4.5 GHz” maps to nothing without the sustained figure. “Unmetered bandwidth” maps to nothing without a port speed and a commit.

• CPU: exact model, base clock, sustained all-core clock under load.
• RAM: capacity, ECC yes or no, populated channels, speed.
• Storage: model number, NAND type, TBW, local or networked.
• Network: port speed, committed rate, overage, prefix size and route quality.
• Support: out-of-band access included, replacement SLA, hands on site.

Turning the table into a purchase decision

List your instances by genre, total the cores, RAM and storage each needs, and add 25% for the hypervisor if you are virtualising on the box. Compare that total against two or three concrete configurations rather than against a price list tier. A configuration that fits the floors and leaves headroom is worth more than a cheaper one that sits exactly on the limit.

Finally, verify on delivery. Run a single-thread benchmark, check memory channels with dmidecode, and confirm the disk model matches the invoice. A node that passes the floors by 15% or more will survive a content update that adds 20% to entity counts; one that passes by 2% will not. Our guide to matching server hardware to player count goes deeper on the sizing arithmetic per genre, and the specification floors above are the input to that calculation.