Game Server Hardware: What Actually Matters

Ask what hardware a game server needs and you will get answers shaped like a shopping list: this many cores, this much RAM, this kind of disk. The list is usually wrong, and it is wrong in a specific direction — too many cores, too little attention to what each core can actually do, and far more capacity than the server will ever use.

Game servers have an unusual performance profile compared with almost everything else you might run on a machine. Understanding that profile is worth more than any spec sheet, because it tells you which number to care about and which numbers you can safely ignore.

One core does the work

Here is the thing that reorders every other decision. Most game servers run their simulation on a single thread.

The reason is structural rather than lazy engineering. A game world is a tick loop: read player input, run physics, update entities, resolve interactions, send state back out. Every step depends on the one before it, and everything in the world can potentially interact with everything else. Splitting that across cores means locking shared state constantly, and the coordination overhead frequently costs more than the parallelism gains. So the main loop stays on one thread, and that thread's speed sets the ceiling on how much world your server can simulate.

The practical consequence: a processor with fewer, faster cores will run most game servers better than one with many slower cores, even when the second has far more total throughput. Server-grade chips designed for many simultaneous workloads often have lower per-core clocks than a desktop chip aimed at responsiveness, which is why a modest desktop-class machine can outperform a much more expensive multi-core server for this one job.

What this looks like when you exceed the ceiling depends on the game, and the vocabulary differs. Minecraft reports it as tick time going above the budget, showing up as TPS falling below twenty. Source-engine games show a falling server tick rate or a rising frame time. FiveM reports resource-level timings and a server-side hitch counter. All of them are describing the same thing: the main thread ran out of time in the tick and everything after it arrived late.

Watch that number rather than CPU utilisation, because they disagree in a way that misleads people constantly. A machine showing modest overall CPU use can have its one important thread completely saturated. On a four-core box, one pinned core reads as low utilisation on an overall usage graph while the server is already dropping ticks. Look at per-core figures, or better, look at the game's own tick metric.

The exceptions

Some things genuinely do use additional cores, and they matter enough to be worth knowing.

Chunk generation and world loading in Minecraft is parallelised in most modern server software, so exploring a fresh world will use more than one core even though the main tick does not. The choice of server software affects how much — the differences between the common options are covered in the Paper, Purpur and Fabric comparison.

Network I/O typically runs on its own threads, as does compression, world saving in some implementations, and any database work.

Running several servers on one machine is the clearest case. Four separate instances will genuinely use four cores, because they are four independent processes. This is why a multi-core machine makes sense for someone hosting a small network of servers and not for someone hosting one big one.

Some newer engines have moved more of the simulation off the main thread. It is a real trend, but it has not changed the basic picture for the games most people run.

RAM is where you actually run out

Single-thread performance sets your quality ceiling. Memory sets your hard limit, and it is usually the first wall you hit.

A game server holds the loaded world, every active entity, all connected player state, and whatever mods and plugins have allocated. Run out and the outcome is not gradual degradation — it is the process being killed, or on a JVM, garbage collection pauses so severe the server is unusable while technically still running.

What actually consumes it varies by game. For Minecraft, loaded chunks dominate, which means memory scales with how spread out your players are far more than with how many there are. Ten players in one town use less than three players exploring in three directions. For Rust and 7 Days to Die, it is the persistent world and every structure players have built, which grows steadily over a wipe cycle regardless of who is online. For FiveM, it is the loaded resources, and a server with many scripts can use a lot with nobody connected at all.

Modded content changes the picture completely, and this is where most planning goes wrong. A large modpack can need several times what the vanilla game needs before a single player joins, because mods add entities, tile entities, dimensions, recipe registries and item definitions that all exist in memory whether anyone is using them or not. That cost is largely fixed. It is paid at startup, it does not scale down when the server is empty, and it means a modded server for a handful of friends can need more memory than a vanilla server for a large crowd.

Two practical points that catch people out.

For JVM-based servers, allocating the whole machine's memory to the heap is a mistake. The JVM needs space outside the heap, and the operating system needs room to cache files. Leave meaningful headroom. Over-allocating also lengthens garbage collection pauses, which players feel as periodic freezes — more heap is not automatically better.

Swap is not a safety net. A game server paging to disk does not run slowly, it becomes unplayable, and the symptoms look like network problems rather than memory problems. If you find yourself relying on swap, you need more RAM, not more patience.

Disk: when it matters and when it does not

Disk is where advice tends to be strongest and least justified. The honest answer is that it matters intensely for a few specific operations and barely at all the rest of the time.

It matters for world loading. Starting a server, generating new terrain, or streaming in areas as players explore all hit the disk hard, and the difference between a mechanical drive and solid-state storage here is not subtle — it is the difference between a startup you wait through and one you barely notice. On a large persistent world it is the single most noticeable hardware difference.

It matters for periodic saves. Most servers write world state on an interval, and on a mechanical drive that write can stall the main thread long enough for players to feel a hitch every few minutes. People chase this as a lag problem for weeks before realising it is the save cycle.

It matters for custom content transfer. Source-engine servers sending custom maps and assets to connecting players read from disk during the download, and on a busy Garry's Mod or Counter-Strike: Source server with a large content set that read pattern is unhelpfully random.

It matters for logs, which is easy to forget until a full disk takes the server down.

It does not matter much once the world is loaded and running. Steady-state gameplay is mostly memory and CPU. A server sitting on a loaded world with a stable player group touches disk relatively little between saves.

So: solid-state storage is worth having and is close to universal now anyway. Beyond that, the difference between a fast NVMe drive and an ordinary SATA SSD is real but small for this workload, and paying a premium for the fastest available storage is usually money that would do more good as RAM. Capacity is rarely the issue — game worlds are modest by modern standards — except for servers with large custom content libraries or long backup retention.

Bandwidth is not your problem, latency is

This is the assumption that costs people the most unnecessary money.

Game servers send small packets very frequently. The per-player bandwidth is genuinely low compared with almost anything else you might host — a video stream, a file server, a busy website. A modest connection carries a full server comfortably, and residential upload speeds are the more common constraint rather than anything you would rent.

Where bandwidth does become relevant is in bursts rather than in average throughput. Players downloading custom content on connection, world downloads, and backup transfers all produce short heavy loads. If those share the same link as gameplay traffic, players in game feel it. Separating the two, or rate-limiting the downloads, solves it more cheaply than a bigger pipe.

Latency is the thing that actually determines whether your server feels good. It sets how long a player waits between acting and seeing the result, and it is dominated by physical distance and routing quality rather than by any hardware you can buy. A powerful machine in the wrong location plays worse than a modest one near your players, and no amount of CPU fixes it.

That makes location the most important networking decision you make, and it should follow your intended community rather than your own address. It also means bandwidth marketing is a poor guide to quality. A host advertising enormous port speeds may still route badly to the region you care about. Test the actual path — latency and packet loss from where your players are — before committing.

Packet loss deserves separate mention because it is worse than latency for gameplay and less visible in any specification. A connection with a consistent moderate delay plays acceptably. One with a low average and intermittent loss feels broken, and it will be blamed on your server rather than the network. This is also why absorbing attack traffic matters more than raw capacity for a small server; what to actually do about DDoS on a small server covers the practical side.

Player count does not scale the way you expect

The instinct is that doubling players doubles the load. It is not that simple, in both directions.

Some costs are close to linear. Network traffic roughly tracks the number of connections. Per-player state does too.

Some costs are worse than linear, and these are the ones that hurt. Entity interactions grow faster than player count, because more players means more built structures, more spawned entities, more things checking against each other every tick. In an open world, players spread out, and spread-out players force more of the world to stay loaded — the world-loading cost tracks distribution rather than headcount. Physics and collision work rises faster than the number of participants when players cluster.

Some costs are fixed regardless. Loaded mods and resources cost the same at one player as at fifty. World simulation ticks along whether anyone is watching.

The result is that the same machine might handle a small group easily, a medium group with occasional strain, and a larger group badly — with the falling-off point arriving suddenly rather than gradually. And the number is entirely game-dependent. A Team Fortress 2 server with a fixed map and no persistent building behaves very differently from a Rust server where the world accumulates structures over weeks. Working out a sensible cap for your particular case is its own exercise, and choosing a slot count goes through it properly.

Buying for a population you do not have

The most common and most expensive mistake is provisioning for the server you hope to run rather than the one you have.

It goes like this. You plan for a large community, buy hardware sized for it, and then run at a fraction of that for months. You have paid the full cost the whole time. Worse, the extra capacity did nothing for the players who did show up — a server that is half-idle does not play better than one that is comfortably loaded, so the money bought no experience improvement at all.

The reasoning behind it is understandable: nobody wants the server to fall over on the night it gets busy. But the risk is asymmetric in the opposite direction to how it feels. Being briefly over capacity on a good night is a small, recoverable problem. Paying for unused capacity for six months is a real cost that compounds, and it is one of the more reliable reasons small servers shut down — the operator gets tired of the bill before the community arrives.

Start smaller than feels comfortable. Measure. Scale when the measurements say to. Growth in player numbers is gradual enough that you will see it coming, and most hosting arrangements let you increase resources with minimal disruption. If a spike does arrive, a temporarily strained server that you upgrade the next day is a far better outcome than months of paying for nothing. The cost breakdown for 2026 is worth reading before you commit to anything, and browsing what similar servers are actually running on the server list gives you a sense of what your kind of community realistically needs.

One related trap: matching a large public server's specification because you want to be like it. That server is sized for its current population, not its first month. Copying its hardware gets you its costs without its players.

Finding the actual bottleneck

Guessing which resource is limiting you leads to buying the wrong thing. There are only a handful of candidates and each has a distinct signature.

If the game's own tick or frame time is over budget while overall CPU use looks moderate, you are limited by single-thread performance. Check per-core figures to confirm one core is pinned. More cores will not help; a faster core will, and so will reducing the simulation work — fewer entities, tighter view distances, fewer plugins doing per-tick work.

If memory use sits near the ceiling, or the process is being killed, or a JVM server shows long garbage collection pauses, you are memory-limited. Watch it over days rather than minutes, because the pattern that matters is a floor that creeps upward after each restart. That is a leak, and it tells you a restart schedule is doing real work.

If you see stalls during saves or world loading while everything else looks fine, that is disk. It is easy to confirm — the hitches line up with the save interval.

If players report problems that your server-side metrics do not show at all, look at the network. Test latency and loss from where the players are, not from the server, since the server sees a healthy machine either way. This is the case where every internal graph looks perfect and the experience is still bad.

If nothing is near a limit and the server still plays badly, the cause is usually configuration or a specific plugin rather than hardware. A single badly-behaved script can consume the tick budget by itself while every resource graph stays flat.

The general method is straightforward. Record baseline figures when the server is running well and empty. Record them again at your typical population. Record them again during your busiest hour. Compare the three. Whichever number moved most is what you are limited by, and it is frequently not the one you assumed. Watching a Counter-Strike 1.6 or Left 4 Dead 2 server this way for a week will teach you more about its behaviour than any specification document.

FAQ

How many cores does a game server need? Fewer than you think. Most run their simulation on one thread, so per-core speed matters far more than core count. Extra cores help when you run multiple server instances on one machine, or for background work like chunk generation and world saving.

How much RAM should I allocate? Enough for the loaded world, active entities, connected players and every mod, with headroom left for the operating system. Modded content is the main variable, and its cost is mostly fixed at startup rather than scaling with players. For JVM servers, do not allocate the entire machine to the heap — it lengthens garbage collection pauses and starves the file cache.

Do I need an NVMe drive? Solid-state storage genuinely helps world loading, save cycles and custom content transfer. The step up from a SATA SSD to the fastest NVMe available is much smaller for this workload, and that money usually does more as RAM.

How much bandwidth does a game server use? Less than most people expect. Steady gameplay is many small packets rather than high throughput. The bursts — content downloads on connection, backups — are what saturate a link, and separating or rate-limiting them is cheaper than a larger connection.

Where should I host it? Near your intended players. Latency is set by distance and routing, and no hardware compensates for a bad path. Test latency and packet loss from your players' location before committing, and treat advertised port speeds as a weak signal of quality.

Why is my server lagging when nothing looks maxed out? Most often one saturated thread hidden inside a low overall CPU figure, or a single plugin consuming the tick budget. Look at the game's own tick metric and per-core usage rather than the overall usage graph.

Should I buy extra capacity for growth? No. Spare capacity does not improve the experience for the players you already have, and paying for it for months is a common reason small servers close. Start small, measure, and upgrade when the measurements say to — you will see growth coming.