Game server CPU: clock speed vs cores

Almost every game server runs its simulation on one thread, so the CPU requirement is not "how many cores" but "how fast is one core, and is it mine when I need it". A typical server needs one fast core for the main loop plus a half to one extra core for saving, networking and garbage collection - which is why 1.5 to 2 vCPU covers most games and why 8 slow cores lose to 2 fast ones every time. The exceptions are real but short: Factorio's huge factories, heavily scripted Arma and FiveM servers, and modded survival games that do world generation on the side. This post explains why the main thread decides everything, gives the realistic core count per game, and shows how to prove the CPU is your limit before you pay for more of it.

The main thread does the work#

A game server is a loop. Every tick it reads player input, moves every entity, resolves hits, runs scripts and plugins, and sends each client a snapshot of what changed. Then it sleeps until the next tick. The loop runs at a fixed rate, and each rate gives the server a fixed budget of time per tick:

The important property of that loop is that it is sequential. Entity B's movement depends on where entity A ended up, a plugin's event handler runs after the event it handles, and the snapshot is built after everything else is finished. Engines can and do push side jobs onto other threads - chunk loading, pathfinding requests, compression, disk writes - but the simulation itself has to happen in order, on one thread, inside the budget. When it does not fit, the tick is late, and players feel a late tick as rubber-banding, delayed hits and doors that open a second after they press the key. What tick rate actually means goes into how each engine reports it.

That is the whole reason clock speed matters more than core count. A core that runs 30% faster finishes every tick 30% sooner. A second core helps only with the work that was already off the main thread, and once that work has somewhere to run, a third and fourth core sit idle.

What a vCPU and a CPU percentage actually buy#

Hosting sells CPU in two ways, and they mean different things.

A vCPU on a virtual machine is usually one hardware thread. On a processor with hyper-threading or SMT, each physical core presents two threads, and two busy threads on one core share its execution units, so each gets noticeably less than a full core. Some hosts sell one vCPU as one physical core and some sell it as one thread; the label does not tell you which.

A CPU percentage is how Pterodactyl and most container panels express it. 100 means one core's worth of time, 150 means one and a half, 250 means two and a half. It is enforced by the kernel's CPU accounting, so a server at its limit is throttled until the next accounting period. On RE:NODE that limit is a hard throttle to the share you bought: a server can use exactly that much and no more, and a server sitting at 100% of its share is slow, not broken, and is never suspended for it.

The practical consequence for a game: a 1.5 vCPU limit is one full core for the main thread plus half a core for everything else. A 2.5 vCPU limit is one full core plus one and a half for everything else. Neither makes the main thread faster than one core can go. If your server's main thread already gets a full core, a higher tier helps only if the "everything else" was being squeezed - which does happen, mainly during saves, during world generation and when the garbage collector runs.

Shared CPU and noisy neighbours covers the other half of the question: whether your share is a reservation or a leftover, and how to measure steal time from inside a server.

How many cores each game really uses#

These are realistic figures for a normal group on a stock or lightly modded server. "Main thread" is the work that cannot be split; "side work" is what benefits from a second core.

Three things stand out.

First, the bottom of the table is not "weak". Terraria and Counter-Strike 1.6 genuinely use a fraction of a modern core. Buying them more is buying idle time.

Second, the games near the top of the table are there because their side work is large, not because the simulation scales. A Rust server writes a save of tens or hundreds of megabytes on an interval and runs a garbage collector over a large managed heap; both want a core that is not the main thread. 7 Days to Die builds chunk meshes and runs a lot of zombie AI pathing. None of them gets a faster tick from a fifth core.

Third, two games solve CPU limits by running more processes rather than more threads. Arma 3 moves AI onto headless clients - separate game processes that connect to the server like players and take over AI groups - so a mission with hundreds of AI units uses three or four cores as three or four main threads. Arma 3 headless clients covers the setup. Don't Starve Together runs the overworld and the caves as two server processes, so a cluster with caves is two main threads sharing one allocation.

Single-core speed: what to compare#

If you are choosing hardware for a VDS or comparing hosts, compare single-thread performance, not core count or a total benchmark score.

• Single-thread benchmark scores (Geekbench single-core, PassMark single-thread, Cinebench single-core) are the closest proxy to tick time. A multi-core score multiplies the wrong number.
• Boost clock matters more than base clock, but only if the boost is sustained. A desktop part running one core at full boost all day behaves very differently from a dense server part whose all-core clock under load is a gigahertz lower.
• Cache matters for simulations. Games walk large lists of entities and chunks every tick; a processor with more cache per core keeps more of that list close, which is why some desktop parts with large caches outperform server chips with higher core counts on game workloads.
• Generation matters. A recent desktop core at the same clock does noticeably more per tick than one from five generations ago. Clock speed alone is not comparable across architectures.

The honest answer for most people renting a game server is that you will not be told the exact processor and cannot choose it, so the benchmark you can trust is your own server's tick time under your own load. On RE:NODE the only processor model stated is the Intel i9-9900K on the VDS line; the shared game nodes do not have a stated model, and the tick-time methods below work the same on any of them.

Proving the CPU is the limit#

Before buying anything, check that the CPU really is what runs out. The memory-versus-CPU question is the most common sizing mistake, and CPU or RAM: which one is holding your server back is the long version.

Read the game's own tick numbers

Every serious game server reports how long its ticks take. Learn where yours does:

• Minecraft: /mspt on Paper or /spark tps. MSPT above about 40-45 is a server near its limit; TPS falling below 20 means it is past it.
• Factorio: the number is UPS, which a connected client can display through the F4 debug options. A factory that cannot hold 60 UPS is CPU-bound by definition, and every player slows down with it.
• Rust: server.fps reports the current server frame rate. A healthy server runs well above 30; one sliding towards single digits during raids is out of main-thread time.
• Arma 3: #monitor 1 from an admin client prints server FPS and memory every second. Server FPS under about 20 is where AI and vehicles visibly suffer.
• Source games: stats in the server console shows CPU, in/out traffic, uptime and FPS.
• FiveM: the server warns in its own console when a tick takes too long, and profiler record captures where the time went.

Read the graph against the limit

The panel's CPU graph is measured against the allocation. Three shapes, three meanings:

1. Flat at the limit while players complain. The allocation is the ceiling. A higher tier helps if there is real side work to absorb.
2. Well below the limit while players complain. The main thread is maxed at roughly one core, or something else is wrong. More allocation will not help; less work per tick will.
3. Spikes at regular intervals. Saves, scheduled tasks or backups. Check whether the spikes line up with the lag reports before you change anything.

Look at threads, not the process

On a VDS or your own machine you can see each thread separately:

$ top -H -p "$(pgrep -f RustDedicated)"$ pidstat -t -p "$(pgrep -f RustDedicated)" 1

top -H lists threads instead of processes. If one thread sits at 98-100% while the rest are near idle, that is the main thread, and that is the ceiling. pidstat -t (from the sysstat package) gives the same view as a rolling log you can leave running during a busy evening. Swap the process name for your game's binary. Reading game server CPU usage explains the single-thread picture in more depth, and reading a server load graph covers the panel side.

What raises CPU use without raising players#

Most CPU problems are created by the people running the server, not the people playing on it. In order of how often they turn up:

• Plugins and scripts. Every Minecraft plugin event handler, every SourceMod plugin, every FiveM resource with a while true loop and a short wait runs on the main thread. A single badly written one can cost more than thirty players. Profilers exist for this - spark, the FiveM profiler, SourceMod's own profiler - and they name the culprit.
• Entities. Mob farms, item piles, Rust's deployables, Zomboid's zombie population, ARK's tames, 7 Days to Die's horde. CPU scales with what has to be updated each tick, and entity counts grow quietly between restarts.
• World generation. Exploring new terrain is the most expensive thing most survival and sandbox servers do. Pregenerating the map (Minecraft's Chunky, Rust's fixed-seed maps generated once) moves that cost to a quiet hour.
• Simulation distance. Minecraft's simulation-distance, 7 Days to Die's ServerMaxAllowedViewDistance, DayZ's network bubble - every setting that widens the active area multiplies the per-tick work.
• Tick rate itself. Running a Source game at 128 tick halves the budget per tick compared with 64. For a CS2 competitive server that is the point; for a casual server it is CPU spent on nothing.

Per-game notes worth knowing#

Minecraft. Paper moves chunk loading and some lighting work off the main thread, which is why a Paper server uses more than one core without any one setting asking it to. Folia goes further and splits the world into regions that tick on separate threads, but it breaks most plugins; it is for large servers that have outgrown everything else. For everyone else, Paper optimisation is where CPU is won.

Factorio. Factorio's update is deterministic and lockstep: every client runs the same simulation, so the server is only as fast as the slowest machine that must keep up. Parts of the update have been parallelised in recent versions, but large factories remain bound by one core. Fewer entities, fewer belts with items on them and fewer inserters checking empty chests are what restore UPS. Factorio mods and UPS performance has the specifics.

Rust. Rust's cost is entity count. A server on wipe day and the same server six days later are different machines, because every building block and deployable is an entity the server has to network to anyone near it. CPU climbs through the wipe cycle alongside memory.

Shooters. Counter-Strike 2, TF2 and Insurgency: Sandstorm load a fixed map and keep it in memory; their cost is per-tick work for each player, which is small and constant. A stock CS2 server for ten players barely notices. What changes it is plugins, bots and GOTV.

Unreal engine survival games. Palworld, ARK, The Front, Satisfactory and Soulmask run the Unreal dedicated server, which does use several threads for networking, loading and physics. Their main game thread is still the limit when bases get large, and their memory appetite usually forces a tier with enough CPU anyway.

Choosing the CPU share#

A short decision path that holds for most games:

1. Start at the share recommended for the game: 1-1.5 vCPU for light games, 2 for survival and sandbox games, 2.5-3 for large modded or scripted servers.
2. Run it for a week with real players and read the game's own tick numbers during the busiest hour, not the average.
3. If tick time is healthy, stop. Extra CPU share will not be felt.
4. If tick time is bad and the panel graph is flat at the allocation, move up a tier. On RE:NODE the CPU share rises with each tier, and changing plan changes the limit on the server you already have rather than rebuilding it.
5. If tick time is bad and the graph is below the allocation, the main thread is the ceiling. Profile and remove load; no tier will fix it.

Most RE:NODE game plans run from 0.5 vCPU on the smallest Terraria and Counter-Strike 1.6 tiers up to 3.5 on the largest survival tiers, with RAM and disk rising in step. Game server requirements by game gives the starting point for every title in one table.

FAQ#

Do game servers use multiple cores?

Some of the work, yes: saving, loading, networking, garbage collection and in some engines chunk generation or physics. The simulation itself almost always runs on one thread. That is why two cores help a lot over one, and eight help almost nothing over two.

Is hyper-threading bad for game servers?

Not bad, but a hyper-thread is not a core. Two busy threads on one physical core share it, so a main thread placed next to a busy sibling runs slower than it would alone. On a VDS this is worth knowing when you assign cores; on shared hosting it is part of what you rent and cannot see.

Why is my server lagging when CPU usage is only 40%?

Because the percentage is averaged over the allocation and over the sampling interval. A server with 2.5 vCPU whose main thread is saturated shows roughly 40% of the allocation in use while being completely out of tick time. Read the game's tick or FPS figure instead.

Will a faster CPU fix rubber-banding?

Only if the rubber-banding comes from late ticks. If the game's tick figures are healthy, the cause is network latency, packet loss or, in games like Valheim, a player with a poor connection simulating part of the world. Check tick times first, then the network.

How much CPU does a modded server need?

Usually one tier more than the stock game, and it depends on what the mods do rather than how many there are. Content mods that only add items cost little per tick. Mods that add machines, AI, automation or per-tick scripts cost a lot. Profile with the game's own tools before and after adding a big one.