What CPU Do I Have: Reading the Answer on Linux, Windows and a VPS

On Linux the answer is lscpu, on Windows it is the System Information panel or a one-line PowerShell query, and on a virtual server the model name it reports is the host’s processor rather than anything you exclusively own.

That last point is the one worth the article. On a physical machine, knowing the processor tells you what performance to expect. On a virtual server it tells you what silicon is underneath, which is only half the story, because how much of it you get depends on whether your cores are dedicated and how busy your neighbours are.

So this covers reading the model, and then reading the numbers that actually predict performance.

Table of contents

• Getting the model name
• Cores, threads and the number that matters
• On a virtual server, the model is only half the answer
• Measuring rather than reading
• When the CPU is the wrong thing to be looking at
• How this fits the rest of the stack
• FAQ

Getting the model name

On Linux, one command covers almost everything:

lscpu

# Or just the essentials:
lscpu | grep -E 'Model name|Socket|Core\(s\) per socket|Thread\(s\) per core|^CPU\(s\)|MHz|Hypervisor'

The raw source, if lscpu is unavailable on a minimal image:

grep -m1 'model name' /proc/cpuinfo
grep -c ^processor /proc/cpuinfo    # logical processor count

On Windows, PowerShell gives it directly:

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

Or without a terminal: press the Windows key, type About, and read the Processor line under Device specifications.

On macOS:

sysctl -n machdep.cpu.brand_string
sysctl -n hw.physicalcpu hw.logicalcpu

Cores, threads and the number that matters

The lscpu output has three counts and confusing them leads to bad capacity decisions.

• Socket(s): physical processor packages. Almost always 1 outside servers.
• Core(s) per socket: real, independent execution cores.
• Thread(s) per core: 2 where simultaneous multithreading is enabled, 1 where it is not.
• CPU(s): the product of all three, and the number the operating system schedules onto.

The trap is treating logical processors as if they were cores. Two threads on one core share execution resources; they are not two cores. Depending on the workload, the second thread adds somewhere between very little and about 30% of a core’s throughput, and for cache-heavy work it can be slightly negative.

So a machine reporting 8 CPUs with 4 cores and 2 threads per core is not equivalent to a 8-core machine. For sizing worker pools, start from the physical core count and test upward rather than assuming the logical count is your parallelism budget.

The generation matters as much as the count. A model name including the generation tells you a great deal about per-core performance, and per-core performance is what sets latency for most web workloads, since a single request is usually handled by a single thread.

On a virtual server, the model is only half the answer

In a virtual machine, lscpu reports the host’s processor and a Hypervisor vendor line confirming you are virtualised. Both are useful. Neither tells you how much of that processor is yours.

The number that does is steal time: the percentage of time your virtual CPU was ready to run and the hypervisor scheduled another tenant instead.

# The 'st' column.
vmstat 1 10

# Per-CPU, with more detail.
mpstat -P ALL 2 10

Under 1% is healthy. Between 1% and 5% is a busy host you will occasionally notice. Sustained double digits means the machine is oversubscribed, and at that point the processor model is irrelevant because you are not getting it.

Check it at different times of day. Contention is bursty, and a quiet Tuesday morning reading says nothing about Saturday evening.

The second thing the model does not tell you is whether you are on a burstable plan with a baseline and a credit balance. Run above the baseline continuously and credits deplete, after which performance drops sharply. That behaviour is invisible in lscpu and is frequently the real explanation for a server that was fast for a week and then was not.

Measuring rather than reading

If the question behind what CPU do I have is really is this fast enough, the answer comes from a benchmark rather than a model number.

# Single-threaded, which sets your request latency.
sysbench cpu --cpu-max-prime=20000 --threads=1 run

# Then all cores, to see how well it scales.
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

The ratio between those two is the informative part. On dedicated cores, throughput scales close to linearly with thread count. On shared or burstable cores it does not, and the gap is a direct measure of what you actually bought versus what the spec sheet said.

Watch the temperature and frequency too on a physical machine, because sustained load can trigger thermal throttling that a short benchmark never reveals:

watch -n1 "grep 'MHz' /proc/cpuinfo | head -8"

A clock speed that starts high and settles considerably lower under sustained load is throttling, and it means your benchmark number and your production number will differ.

When the CPU is the wrong thing to be looking at

It is worth checking whether the processor is actually your constraint before optimising around it, because for most web applications it is not.

A quick triage:

1. High CPU utilisation with low steal time: genuinely CPU-bound. Profile the hot path, or size up.
2. Low CPU utilisation but slow responses: you are waiting on something. Almost always the database or an external call, and no amount of CPU helps.
3. High load average with low CPU: processes blocked on IO. Look at disk latency and network waits.
4. High steal time: contention. Not your workload, and not fixable from inside the machine.
5. Memory pressure with swapping: everything looks slow and the processor is not the reason.

The second case is the most common by a wide margin. A request spending 400ms waiting on an unindexed query and 12ms computing is not a processor problem, and doubling the vCPU count changes it by nothing measurable.

When sizing is genuinely the answer, the practical move on a managed platform is to move up a plan and let autoscaling handle the peaks rather than provisioning for the worst case permanently. The autoscaling documentation covers setting a floor and a ceiling on RunxBuild.

How this fits the rest of the stack

Choosing a plan by processor specification alone tends to over-provision the compute and under-provision everything else, since the database, the storage and the egress are usually the lines that grow fastest. The RunxBuild hosting calculator shows the vCPU and RAM ladder alongside those, which turns sizing into arithmetic instead of a guess anchored on a model number.

Useful related references:

• Rust Cow: Clone Only When You Actually Have To
• Regex in Golang: RE2, MustCompile, and the Backreference You Cannot Have
• PostgreSQL CREATE DATABASE IF NOT EXISTS: The Workaround Postgres Does Not Have
• Services on RunxBuild

FAQ

How do I check my CPU on Linux?

Run lscpu for a formatted summary including model name, core count, threads per core and whether you are virtualised. On a minimal system without lscpu, read /proc/cpuinfo directly: grep for model name, and count lines starting with processor for the logical CPU count.

What is the difference between cores and threads?

A core is an independent execution unit; threads are hardware scheduling contexts sharing a core’s resources. Two threads on one core deliver somewhere between very little and roughly 30% more throughput than one, depending on workload. Size worker pools from physical cores and test upward rather than assuming logical count.

Why does my VPS show a processor I do not recognise?

Because it reports the host machine’s processor, which you share with other tenants. The model tells you what silicon is underneath but not how much of it is allocated to you. Check steal time with vmstat to find out whether you are actually getting the capacity you paid for.

What is steal time and why does it matter?

It is the percentage of time your virtual CPU was ready to run but the hypervisor scheduled another tenant instead. Under 1% is normal; sustained double digits means the host is oversubscribed. It is the single most useful performance diagnostic on a virtual server and it is not visible from any provider dashboard.

How do I know if my CPU is the bottleneck?

Check utilisation alongside steal time and response times. High CPU with low steal means genuinely CPU-bound. Low CPU with slow responses means you are waiting on something else, usually the database, and adding processor capacity will change nothing. That second case is by far the more common.