Right-Sizing Your Game Server Resource Requests

Most game server resource requests are wrong. Not catastrophically wrong, just slightly wrong in ways that don't surface until you're trying to figure out why your node has 30 cores free but won't schedule another server.

The problem is where those numbers come from. A developer runs the game server binary on their workstation, watches CPU and memory in Task Manager, and puts those figures in the manifest. That number reflects a single idle server on a development machine. It does not reflect a server under player load, on a production node, alongside 80 other servers competing for cache and network bandwidth.

The scheduler believes the manifest. It has no other source of truth.

What Happens When You Get It Wrong

Overestimating resources (setting requests higher than actual consumption) is the most common mistake. It feels safe. In practice, it artificially caps your server density. If each server requests 2 CPU cores but only consumes 0.6 under real load, you're packing 50 servers onto a node that could hold 150. The headroom exists. The scheduler can't see it.

On bare metal, GameFabric supports up to 150 dedicated game servers per node. That ceiling assumes sane resource requests. Inflate your CPU request by 3x and you're operating at a fraction of the hardware's actual capacity, paying for metal that sits idle.

Underestimating resources creates the opposite problem: servers that starve under player load. CPU throttling degrades tick rate and latency in ways that are easy to attribute to the game and difficult to trace back to the manifest. Memory underestimates are worse because pods get evicted mid-session.

Both failure modes share a root cause: resource requests written against the wrong environment.

How to Get the Right Number

The answer is profiling under real load, not estimation.

GameFabric includes eBPF-based continuous CPU profiling via Grafana Pyroscope, with an overhead of 2–3%. You enable it on an Armada or Vessel, and it collects live flame graphs against your production game servers. Not your dev machine, not a synthetic benchmark, but actual servers running actual sessions with actual players.

That data tells you what a server genuinely consumes under normal load and at peak. From there, a reasonable resource request adds a modest buffer above your observed peak without padding in the dev-environment safety margin you no longer need.

The Grafana monitoring stack also surfaces this directly: the Current Gameservers dashboard exposes per-server CPU and memory consumption alongside your configured requests, so you can see the gap in real time and close it.

The Compounding Effect

Resource request accuracy is not just an efficiency concern. It directly determines how many dedicated game servers you can schedule per node, which determines how many nodes you need, which determines your hosting cost at any given player population.

Getting it right is a one-time calibration that pays off continuously. Getting it wrong is a tax you pay on every server, every session, forever.

Enable profiling on your Armadas and start with the data you actually have. See the GameFabric documentation.