Server CPU Sizing: Cores, Clock Speed and the Licensing Bill

There are four licensing shapes in a typical rack, and they pull in different directions. Per-core with a floor — the model VMware moved to under Broadcom, and the model Windows Server has used since 2016 — charges for every physical core in the host and refuses to charge for fewer than a stated minimum. Per-core without a meaningful floor, which is roughly how SQL Server behaves above its four-core-per-processor minimum, charges strictly for what you deploy. Per-socket or per-system subscriptions, common in the Linux world, are largely indifferent to core count. And processor-factor models, of which Oracle's Core Factor Table is the best-known, multiply physical cores by a published coefficient before charging.

The practical consequence is that the same workload can have two very different five-year costs depending on which of those models dominates your stack. A virtualization host running a per-core hypervisor and a per-core guest OS is charged twice for every core you add. A bare-metal Linux application server on a per-system subscription is charged once for the box, and the core count is nearly free. Nobody can tell you which processor to buy without knowing which of those two your host is.

Two floors are worth memorizing because they are the ones that produce invisible waste. The per-CPU minimum reported for VMware Cloud Foundation means a host built with sub-16-core processors licenses cores it does not have; buying an 8-core part to save on licensing achieves nothing at all, and the cheaper silicon is simply lost value. Windows Server's minimums work the same way from the other end: eight core licenses per physical processor and sixteen per server, so a two-socket host is licensed for at least sixteen cores even if it holds two four-core CPUs. Below those thresholds, adding cores is free in license terms — which usually means the right answer is to go up to the floor, not to stop short of it.

Frequency wins wherever the software bill is proportional to cores and the work is not. The canonical case is a per-core-licensed database. If a workload needs a fixed amount of throughput and you are paying per core to deliver it, then a processor that does more work per core reduces the license count directly. This is why frequency-optimized parts — fewer cores, higher sustained clocks, often a larger cache slice per core — exist as a distinct product line in every server CPU family, and why they can be the cheaper choice overall despite a higher price per socket.

Frequency also wins where the work simply cannot be parallelized. Single-threaded batch jobs, older line-of-business applications, license servers, some engineering and simulation front ends, and most interactive latency-sensitive paths spend their time on one core at a time. Doubling the core count does nothing for them; raising the clock and the per-core cache does. The tell is a monitoring graph showing one or two cores pinned while the rest of the socket idles — a shape that no amount of consolidation planning will fix.

The honest caveat is thermal. Sustained all-core frequency is not the boost number on the datasheet, and the difference between them depends on chassis airflow, ambient temperature and the power limits configured in firmware. A frequency-optimized part in a dense 1U chassis with restricted airflow can hold a lower all-core clock than its specification suggests. If you are buying frequency specifically to reduce a license count, confirm the sustained all-core figure for the exact chassis and cooling configuration, not the marketing peak.

Cores win where the licensing is per-socket, per-system or unlimited-virtualization, and where the work is genuinely parallel. A Linux application estate on a socket-based subscription, a container platform packing many small services, a virtualization host licensed under a Datacenter-style edition that allows unlimited guest instances — all of these convert additional cores into additional capacity without a proportional software bill. In those environments, the density argument for high-core-count processors is straightforward, and the constraint moves to memory and I/O rather than licensing.

Consolidation ratio is the second argument, and it is the one that usually decides. Every physical host carries fixed costs that have nothing to do with its processors: rack units, power and cooling circuits, network ports, out-of-band management, firmware maintenance windows, and per-host software that is charged per instance rather than per core. Halving the host count by doubling the cores per host removes those fixed costs even when the per-core software bill stays flat. That is the real case for density, and it is far more durable than a benchmark comparison.

The ceiling arrives faster than most sizing exercises assume. Cores need memory bandwidth, and memory bandwidth comes from populated channels, not from installed capacity — a host with all its capacity on two channels will starve a high-core-count processor no matter how many gigabytes it reports. Cores also need I/O: a densely consolidated host aggregates the network and storage traffic of everything it absorbed, and that traffic has to fit through the same PCIe lane budget and the same network uplinks. Size the memory channels and the lanes at the same time as the cores, or the density you paid for will not be available.

Once the core count is settled, the population rule follows. Modern server platforms expose six, eight or twelve memory channels per socket depending on generation and vendor, and peak bandwidth requires one module in every channel. A configuration that fills half the channels gives away a large share of the memory bandwidth the processor was designed around, and no amount of extra capacity in the populated channels recovers it. Fill every channel first, then decide capacity.

Module capacity is the second lever, and it is where the higher-density parts earn their price. Filling every channel with one module per channel at a higher capacity keeps the platform at its rated speed grade; reaching the same total by putting two modules in each channel can drop the operating speed on many DDR4 platforms, and the derating depends on rank count and processor model. If the sizing exercise landed on fewer, denser hosts, the modules generally have to get bigger rather than more numerous.

Server memory is also platform-qualified in a way that catches procurement teams out. Registered ECC modules are sold against a specific system vendor's qualified list, and the part that fits one vendor's host is not the part that fits another's, even at identical capacity, speed and rank. Confirm the module against the host it is going into — by system model, not by specification alone.

The four-socket argument is usually made on capacity: twice the sockets carry twice the cores and twice the memory slots in one chassis, which is genuinely useful for a small number of very large workloads — large in-memory databases, consolidation targets that cannot be split, analytics engines sized to a single instance. If your constraint is one workload that must fit in one machine, a four-socket chassis is the honest answer and the rest of this section does not apply.

For everything else, four sockets multiplies the per-CPU floors. Under a per-CPU minimum, four processors means four floors, and a four-socket host built with mid-core-count parts can license substantially more cores than it contains. Four-socket-capable processors also carry a price premium over their two-socket-only equivalents at the same core count, because the extra inter-socket links are silicon you are paying for whether the workload crosses them or not.

Then there is the shape of the memory. Four sockets means four NUMA domains, and a workload whose working set does not fit inside one domain pays a latency penalty on every remote access. Hypervisors and databases both expose tuning for this, and both perform better when the virtual machine or instance fits inside a single domain. Finally, consider blast radius: consolidating onto fewer, larger hosts concentrates more service into each maintenance window and each hardware failure. That is a real operational cost, and it belongs in the comparison alongside the license arithmetic.