Six Numbers That Size a Server Better Than a Model Name

Ask a supplier to quote "a mid-range 2U server" and you will get six quotations that differ by a factor of four in price and by an order of magnitude in what they can actually do. The model name is the last decision in a server specification, not the first. Six numbers come before it, and if you can answer all six, the shortlist usually collapses to two or three platforms on its own.

1. Sustained core demand, not peak

Peak CPU is a poor sizing input because peaks are short, uneven, and usually caused by something that should have been queued. The number that matters is sustained utilisation across a representative fortnight — including month-end, batch windows and whatever your equivalent of a Monday morning login storm looks like.

Take the ninety-fifth percentile of that period rather than the maximum. If existing hardware sits at 35% of sixteen cores at the ninety-fifth percentile, the workload needs roughly six cores of headroom-inclusive capacity, not sixteen. Buying to the observed peak is how estates end up at 8% average utilisation with a power bill sized for a workload that never arrives.

One caveat worth pricing in: per-core software licensing inverts this calculation entirely. Where a database or hypervisor is licensed per core, fewer, faster cores are frequently cheaper over three years than a larger part at a lower clock, even when the silicon costs more up front. Work out the licence position before the core count, not after.

2. Memory per unit of work

Memory is the constraint that most often decides a platform, because it sets both the board and the processor generation. What matters is not total gigabytes but gigabytes per concurrent unit — per virtual machine, per container, per session, per index.

Establish that figure from the current estate, multiply by the target concurrency, then add the hypervisor or OS overhead separately rather than folding it into a rounded-up total. The result tells you the DIMM count and rank organisation, which in turn tells you whether a single-socket board will carry the workload or whether the second socket exists purely to unlock more memory channels. That second case is common and worth naming explicitly, because a dual-socket board bought for memory bandwidth is a different purchase from one bought for cores.

3. Working-set size against storage tier

The question is not how much data you hold. It is how much of it is touched in a typical hour. A forty-terabyte dataset with a two-hundred-gigabyte working set is a flash-cache problem, not an all-flash problem, and the difference is most of the budget.

Measure read and write separately. Write-heavy workloads punish endurance ratings; read-heavy ones punish latency. A drive selected on capacity and sequential throughput alone will look excellent on the datasheet and disappointing in production.

4. Realistic IOPS with a latency ceiling attached

An IOPS figure without a latency ceiling is not a specification, it is a marketing number. Any array will produce a large IOPS figure if you allow the queue to grow without limit. State it as a pair: the operations per second you need, and the ninety-ninth-percentile latency above which the application is considered degraded.

Ten thousand IOPS at under two milliseconds and ten thousand IOPS at under twenty milliseconds are different machines with different price tags. Write both into the requirement and the shortlist narrows immediately.

5. Network capacity at the host, plus the number of paths

Host networking is usually specified as a bandwidth figure when it should be specified as bandwidth plus path count. Two 10GbE links is not the same as one 25GbE link, even where the aggregate is comparable, because the first survives a switch failure and the second does not.

Decide separately whether storage traffic shares those paths. Converged designs are cheaper in port count and more expensive in the specific failure mode where a storage flood starves control-plane traffic. Both are defensible; leaving it undecided is not.

6. Power and thermal budget per rack unit

This is the number that most often gets skipped, and the one most likely to invalidate the other five. A rack with a 6kW supply and a cooling design from a decade of lower-density hardware will not take four modern dual-socket nodes, regardless of what the rails allow.

Establish the available power per rack, the return-air temperature the room actually achieves under load, and the inlet temperature the platform requires at your intended altitude and ambient. High-core-count processors have moved the thermal envelope substantially; a chassis that fits physically may still need airflow the room cannot supply.

Turning the six into a shortlist

With those numbers in hand the specification writes itself in a form a supplier can price: socket count and core target, DIMM slots and populated capacity, drive bays by form factor and interface, PCIe lanes and slot profile for network and storage adapters, power supply rating and redundancy, and rack height.

That is a specification. "A mid-range 2U server" is a wish. The first gets you three comparable quotations; the second gets you three incomparable ones and an argument at the end of it.

A note on headroom

Add headroom deliberately and record why. A common and defensible pattern is to size compute for present demand plus one year of observed growth, and to size memory and drive bays for the full refresh cycle, on the reasoning that DIMMs and drives can be added later while a board and chassis cannot. Headroom applied uniformly across every axis is not caution, it is simply an expensive way of not having measured.