Choosing a CPU
The spec sheet gives you a core count and a clock speed. Which of the two matters depends entirely on what the machine will be doing.
Clock speed wins when work cannot be split
A single request that must be handled from start to finish by one thread runs at the speed of one core. No amount of extra cores helps. This is the normal case for:
- Game servers — almost all of them have a single authoritative tick loop
- Many PHP and Python applications, per request
- Database queries that cannot be parallelised
- Compilation of a single large file, and most interactive work
For these, a processor with fewer, faster cores beats one with many slow ones every time, and the sustained all-core clock matters more than the headline boost figure, which is a brief best case on one core.
Cores win when work is naturally parallel
Many independent jobs at once — virtual machines, containers, concurrent web requests, encoding farms, build servers running many jobs in parallel. Here cores scale almost linearly until something else runs out, which is usually memory bandwidth or the disk.
Hyperthreading, honestly
Two threads share one physical core's execution units. On workloads that stall waiting for memory, the second thread fills the gaps and you gain perhaps 20–30%. On workloads already saturating the core, you gain nothing and latency gets less predictable. Treat a 32-thread processor as 16 cores plus a bonus, never as 32 cores — and be sceptical of any provider that counts threads as cores in its specification.
Cache and memory bandwidth
The number nobody quotes and everybody feels. A large L3 cache keeps hot data off the memory bus; more memory channels populated means more bandwidth for every core. A dual-socket machine with half its memory slots filled can be slower than a single-socket machine with all of them filled, no matter what the core count says. Populate channels evenly — we do this by default, but it is worth knowing why the memory configuration we quote looks the way it does.
One socket or two
Two sockets give you more cores and more memory capacity, at the cost of NUMA: each processor has its own memory, and reaching the other one's memory is slower. Software that is NUMA-aware handles this; software that is not can lose more to remote memory access than it gained from the extra cores.
Check what you have:
lscpu | grep -i numa and numactl --hardware
Pin processes to a node with numactl --cpunodebind=0 --membind=0 if
your workload benefits from staying local. If you are running one big database, a
single socket with plenty of memory is often the better machine.
Checking what you were given
lscpu for the overview, cat /proc/cpuinfo | grep MHz for
what the cores are actually running at under load, and
turbostat if you want to see how clocks behave over time. If the
sustained clock is far below what you expected, tell us — thermal or power
limits are a hardware matter and therefore ours.
Describe the workload instead
Because we build to order, you do not have to choose a part number. Tell us what the machine runs, how many concurrent users or jobs, and whether latency or throughput is the thing you care about. We will quote a processor that fits, and say so plainly if the one you asked for is the wrong shape for the job.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base