Buying a dedicated server usually starts with one choice, which is more cores or faster cores. The right pick depends on how your software uses the CPU. A game server and a build runner need very different chips. In this guide, you will learn a simple way to pick a CPU based on your real workload. Also, you will learn how to test it before you commit.
If you are comparing the dedicated server CPU cores vs. clock speed trade-off for the first time, this is the right place to start.
More cores let your server do many tasks at once. Higher clock speed makes one task finish faster. None of them is always better.
High clock speed wins when your main task cannot be split into parts. If one thread is at 100% and the other cores sit idle, more cores will not help. You need a faster core.
Single-thread speed is how fast one core finishes one task. It controls latency, which is how long one request waits.
Parallel throughput is how much total work all cores finish in a given time. It controls how many tasks you can handle at once.
Here is an example. A report query runs on one core and takes 10 seconds. A CPU with 64 slow cores still takes about 10 seconds, because the query cannot use the other cores. A CPU with 8 fast cores may finish it sooner. But if 500 users send small requests at the same time, the 64-core CPU can serve more of them.
Most real software is mixed. It has one or two busy threads and many light ones. So test your own workload and don't rely on a spec sheet. When you compare dedicated server CPU cores vs clock speed, find out if the slow part of your app is one thread or all of them.
Adding more threads does not give a perfect gain. Locks, shared memory, and slow disks hold it back. This is why doubling the cores rarely doubles the speed.
Cores and clock speed are not the only things that decide how fast a server feels. Three other CPU features also change real speed. Here is what each one does and how to check it on your server.
SMT lets one physical core run two threads. Then, the OS shows two logical CPUs for each core. The two threads share the same core hardware, so a second thread is not a second core. It usually adds some extra throughput, but the gain depends on the workload. Also, it can add jitter to latency-sensitive tasks.
Check if SMT is active on your server with:
A result of 1 means SMT is on. You can turn it off for a test without a reboot. This setting is not saved after a reboot:
To turn it back on, you can use the command below:
If the file does not exist, your kernel or CPU does not support this control. In that case, use the BIOS setting.
Cache is very fast memory inside the CPU. When data is in cache, the core does not wait for RAM. Databases and game servers usually gain from a large cache, because they read the same data again and again. Check cache sizes with:
Servers with two CPU sockets, and some large single-socket CPUs, have more than one NUMA node. Each node has its own CPUs and its own local RAM. A core reads its local RAM fast. It reads RAM from another node more slowly. You can check your layout with:
If numactl is missing, install it. On Debian or Ubuntu, run sudo apt install numactl. On RHEL-based systems, run sudo dnf install numactl.
If your service needs fast response times, you can keep it on one node:
For big databases and VMs, try to keep each process and its memory on the same node.
A CPU's speed on paper is not always the speed you get. Heat, power limits, and shared hardware can lower it. Two things explain most of this, which are sustained clocks and oversubscription.
For a server that works hard all day, the sustained clock matters more than the peak number. The sustained clock is the speed the CPU can hold under a long, heavy load on all cores.
You can watch the real clock while the server is busy:
turbostat comes with the Linux kernel tools package. The package name differs by distro, for example linux-tools-common on Ubuntu. You can also use:
Oversubscription means a host sells more virtual CPUs than it has real CPU threads. It is common on shared hosting and VPS plans. It works fine when most users are idle. It becomes a problem when many users are busy at the same time, because your tasks have to wait for a free CPU slot.
On a VM, check if the host is taking CPU time from you:
A high %steal value means the host is taking CPU time from you. Install mpstat with the sysstat package.
On a dedicated server, no one else is on the hardware. But if you run your own VMs on it, you set the oversubscription ratio.
Different workloads need different CPU features. Use this table to see what matters most for web servers, databases, game servers, build runners, and VM hosts. Test your own workload before making a final choice.
More cores help run many tasks at once. Higher clock speed helps one main thread run faster. More cache usually helps tasks that use the same data.
Always test your server before choosing a CPU. These steps help you see how your workload uses the CPU and whether it needs more cores or faster cores.
Step 1: Find your current CPU layout.
Step 2: Watch your real load. Run your app under a normal busy period. Then, look at each core:
If one core is near 100% and the others are low, you need clock speed. If all cores are busy, you need more cores.
Step 3: Check for CPU waiting. Linux can show how long tasks wait for a CPU. Run:
A rising value means tasks are waiting for CPU time.
Step 4: Run a short single-thread and multi-thread test. Install sysbench first. Then, compare the two results:
sysbench uses one thread by default, and --threads sets more. Look at the events per second line in both runs.
Use these numbers only to compare your own servers. Do not compare them to numbers from other websites, because the settings and system state are different.
Step 5: Test your real app. A synthetic test cannot replace your own load. Use a tool that matches the app, such as pgbench for PostgreSQL or wrk for web servers. For a build runner, time a real build with time make -j$(nproc). Run each test on a few CPU options, with SMT on and off, and compare the results.
Run each test at least three times, and run long tests for 10 minutes or more. This shows you the sustained clock and not only the boost clock.
Use your test results to choose a CPU that fits your workload. Follow these steps to decide between more cores, faster cores, or a mix of both.
If you want to test a plan before you move to bare metal, a Linux VPS is a cheap way to measure your app's behavior. Just remember that a VPS shares the host, so clock and steal results can differ from a dedicated machine.
Once you know whether your workload needs more cores, faster cores, or both, you can compare real dedicated server hosting options by core count, thread count, and frequency range.
Choosing a CPU based only on core count or clock speed can lead to the wrong choice. Avoid these common mistakes when comparing server CPUs:
The right CPU depends on how your server does its work. More cores help with many tasks at once, while faster cores help when one thread does most of the work. Cache, memory, and steady performance also matter.
Start with your workload, test it under a normal busy load, and use the results to compare CPUs. Choose a server that meets your needs today and leaves space for growth.
No. More cores only help when your software can use them at the same time.
It wins when one thread limits your speed, such as in many game servers and single database queries.
A CPU with high clock speed, a large cache, and enough cores for your connections. Add enough RAM and fast NVMe storage too.
Watch per-core load and /proc/pressure/cpu. High load or high pressure means you need more CPU.