Calculate the number of CPU cores needed to handle a target workload and concurrency.
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.
Total load in core-equivalents
total_load = process_count × avg_cpu% / 100
Recommended cores
cores = ceil((total_load × safety_factor) / (target_utilization% / 100))
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.
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.
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.