How Much RAM Does a Server Need? Sizing Without Guessing

Sizing server memory is the decision that most often gets a virtualisation host wrong, in both directions. This covers how to work out the number rather than guessing it.

Start with what the workload actually uses

Not what it is allocated. Not what the last server had.

On an existing estate, measure actual consumption per workload at peak, then total it. Most environments find that allocated memory is far higher than used memory, because virtual machines are provisioned generously and never reviewed.

On a new deployment, use the application vendor’s stated requirements, then add the overheads below. Our host sizing guide covers measuring properly.

Add the overheads people forget

Four of them.

Hypervisor overhead. The platform itself consumes memory on every host, and more with more virtual machines running.

Software-defined storage overhead. Where the platform runs its own storage layer, that consumes memory per host too, and it can be substantial.

Failover capacity. In a cluster, you must be able to lose a host and run its workloads on the others. A three-host cluster sized to exactly its workload cannot survive losing a host. That is the single most common sizing error.

Growth headroom. Whatever you expect to add before the next refresh.

Why over-sizing costs more than it looks

Memory is not free in three ways beyond its price.

Speed falls as slots fill. On many platforms, fully populating memory slots reduces the operating speed. More capacity can mean less bandwidth. Our memory install guide covers this.

Larger modules cost disproportionately more. The largest capacity module always carries a premium, so reaching a total with fewer larger modules is usually more expensive than with more mid-sized ones — until you run out of slots.

Power and heat. Populated memory draws power and adds thermal load, which our TCO guide covers counting.

Why under-sizing costs more still

Because memory is the resource virtualisation hosts run out of first, almost every time.

Processor cores are usually plentiful relative to how virtual machines actually use them. Memory is not shareable in the same way — a virtual machine either has its allocation or it does not, and when the host runs short, performance degrades sharply across everything on it.

So the practical rule: size for memory, and the processor will usually be adequate. A host that runs out of memory with cores to spare is the normal failure; the reverse is rare.

Leaving slots free: the decision that matters later

Reaching your target with half the slots populated leaves room to double capacity later without replacing anything.

Reaching the same target by filling every slot with smaller modules is frequently cheaper today and means the next upgrade requires discarding existing modules, because you have nowhere to put new ones.

Which is right depends on whether you expect to grow. Where growth is likely, leaving slots free is worth paying for. Where the workload is fixed, filling the slots is cheaper.

And note that memory belongs to a processor — a single-processor machine can only use its half of the slots regardless of how many modules you fit. Our memory identification guide covers the population rules.

A worked approach

Five steps.

Total actual peak consumption across the workloads the host will run.

Add hypervisor and storage overhead from the platform’s documentation.

Add failover capacity if clustered: divide the cluster total so any one host can be lost.

Add growth headroom for the period until the next refresh.

Round up to a valid population for the platform, following the population table so channels fill evenly.

That last step matters: a total that cannot be reached with an even channel population will either not perform or not post. Our install guide covers reading the tables.

Frequently asked questions

Tell us your host model and the workloads it will run, and we will size the memory against a valid population for that platform.