CPU Core Requirement Calculator
Calculate the number of CPU cores needed to handle a workload's total CPU demand at a target utilization ceiling.
Inputs
Average CPU utilization each process consumes, where 100% = one full core
Maximum sustained utilization to leave headroom for spikes
Extra multiplier on top of measured load for burst absorption
Recommended CPU Cores
6
Total Load (core-equivalents)
3.00
Exact Required Cores (before rounding)
5.14
Utilization at Recommended Core Count
50.00%
Step by step
Values used
Number of Processes/Workers = 20; Average CPU per Process = 15 %; Target Utilization Ceiling = 70 %; Safety Factor = 1.20
Total load in core-equivalents
total_load = process_count × avg_cpu% / 100
Recommended cores
cores = ceil((total_load × safety_factor) / (target_utilization% / 100))
Recommended CPU Cores
= 6
Total Load (core-equivalents)
= 3.00
Exact Required Cores (before rounding)
= 5.14
Utilization at Recommended Core Count
= 50.00
How it works
Total CPU demand is the sum of each process's average CPU consumption, expressed in core-equivalents (100% = one fully saturated core). Provisioning exactly that many cores would run the system at 100% utilization on average, leaving no headroom for load spikes, garbage collection pauses, or measurement noise — so the raw load is scaled up by a safety factor and then divided by a target utilization ceiling (commonly 60-75%) to arrive at a core count that keeps sustained utilization comfortably below saturation.
Formulas
Total load in core-equivalents
total_load = process_count × avg_cpu% / 100
- n
- process count
- c
- average CPU% per process
Recommended cores
cores = ceil((total_load × safety_factor) / (target_utilization% / 100))
- k
- safety factor
- u
- target utilization as a fraction
Frequently Asked Questions
Why not just provision cores to exactly match measured average load?
Average load hides variance — real workloads spike above their average regularly, and running at 100% utilization means any spike causes queuing, latency increases, or dropped requests. Targeting 60-75% sustained utilization leaves headroom to absorb bursts without user-visible degradation.
What target utilization ceiling should I use?
Latency-sensitive services (web APIs, databases) often target 50-70% to keep response times stable under bursty traffic. Batch or background processing that tolerates queuing delays can safely target higher, 80-90%, since brief saturation just slows throughput rather than dropping requests.
Does this account for hyperthreading or SMT?
No — this calculates physical/logical core count assuming each unit of 'core' matches how CPU% is measured by tools like top or mpstat, which already treat each hyperthread as its own logical CPU. If sizing physical cores specifically, divide the result by the SMT factor (commonly 2) and validate against actual measured throughput, since hyperthreads do not double real compute capacity.