Benchmarking CPU performance on Linux provides a repeatable baseline for comparing systems, sizing virtual machines, or checking whether firmware, kernel, power-profile, or cooling changes reduced compute throughput. A short synthetic run is often the quickest way to confirm whether slower builds, compiles, or batch jobs are actually tied to processor performance.
sysbench cpu measures how quickly the system can calculate prime numbers with a chosen number of worker threads. The result includes events per second, total completed events, and latency percentiles, which makes it useful for comparing single-thread responsiveness, all-thread throughput, and sustained performance with the same workload.
The steps below use sysbench on Ubuntu 24.04 LTS and were validated against the current sysbench cpu defaults. Run the benchmark on an otherwise idle system, keep the same power and cooling conditions between runs, and reuse the same thread count and test length when comparing one machine or configuration against another.
Related: How to benchmark memory speed in Linux
Related: How to test disk speed in Linux
$ nproc 10
Use this value for the all-thread runs so the workload matches the CPUs currently exposed to the host, guest, or container.
$ sysbench cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 7881.02
General statistics:
total time: 10.0001s
total number of events: 78819
Latency (ms):
min: 0.11
avg: 0.13
max: 25.29
95th percentile: 0.13
sum: 9973.69
Threads fairness:
events (avg/stddev): 78819.0000/0.00
execution time (avg/stddev): 9.9737/0.00
The default sysbench cpu run uses one worker thread for 10 seconds with a prime limit of 10000, which makes it a quick single-thread baseline.
$ sysbench cpu --threads=10 run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 10
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 46804.10
General statistics:
total time: 10.0003s
total number of events: 468081
Latency (ms):
min: 0.12
avg: 0.21
max: 101.26
95th percentile: 0.45
sum: 99721.06
Threads fairness:
events (avg/stddev): 46808.1000/2896.48
execution time (avg/stddev): 9.9721/0.01
Replace 10 with the value reported by nproc on the current system. Compare this result with the single-thread baseline to see how well the workload scales across the available threads.
$ sysbench cpu --threads=10 --time=15 run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 10
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 40067.37
General statistics:
total time: 15.0003s
total number of events: 601087
Latency (ms):
min: 0.12
avg: 0.25
max: 175.03
95th percentile: 0.46
sum: 149589.60
Threads fairness:
events (avg/stddev): 60108.7000/2604.52
execution time (avg/stddev): 14.9590/0.02
Longer all-core runs can expose power limits, clock reductions, and thermal throttling, so sustained scores are often lower than short burst scores on the same hardware.
Related: How to view CPU temperature
Related: How to check CPU speed throttling in Linux
Keep threads and time identical between repeated runs so the results stay comparable.