CPU Capacity Planner
Calculate CPU headroom against a target utilization and check if new workloads fit.
Inputs
Common SRE target: 60-70% to leave burst headroom
Headroom (core-equivalent)
4.00
Verdict
Fits — projected utilization after adding the workload is 63.8%, within the 70% target.
Projected Utilization After New Workload
63.75%
New Workload Fits?
true
Step by step
Values used
Current CPU Utilization (%) = 45; Target Max Utilization (%) = 70; CPU Cores = 16; New Workload's Estimated Core Demand = 3
Headroom and fit check
headroom = (target_util% − current_util%) / 100 × cores; fits if new_workload_cores ≤ headroom
Headroom (core-equivalent)
= 4.00
Verdict
= Fits — projected utilization after adding the workload is 63.8%, within the 70% target.
Projected Utilization After New Workload
= 63.75
New Workload Fits?
= Yes
How it works
Capacity planning against a target utilization (rather than 100%) is standard SRE practice — running consistently near 100% CPU leaves no margin for load spikes, kernel/interrupt overhead, or scheduling latency, so teams commonly target 60-80% as the ceiling for steady-state load. Headroom expressed in core-equivalents (the gap between target and current utilization, scaled by core count) gives a concrete answer to 'how much more compute can I add' — directly comparable against a new workload's estimated core demand to check feasibility before deploying it.
Formula
Headroom and fit check
headroom = (target_util% − current_util%) / 100 × cores; fits if new_workload_cores ≤ headroom
- U_{target}
- target utilization %
- U_{cur}
- current utilization %
- c
- core count
- D
- new workload's core demand
Frequently Asked Questions
Why plan capacity against a target below 100% instead of using all available CPU?
Running near 100% utilization leaves no buffer for traffic spikes, background maintenance tasks, or scheduling/interrupt overhead, and queuing delay grows sharply as utilization approaches 100% (see queuing theory — similar to disk queue length behavior). Targeting 60-80% keeps latency predictable under normal variance.
How do I estimate a new workload's core demand before deploying it?
Load-test it in isolation (or in staging) while monitoring CPU time via `pidstat` or cgroup CPU accounting, then convert observed CPU-seconds-per-second-of-wall-clock into a core-count figure — a process consistently using 250% CPU in `top` is demanding roughly 2.5 cores' worth of capacity.
Does this account for the new workload's peak vs. average demand?
No — it uses whatever single core-demand figure you provide, so feed in a peak or P95 estimate rather than an average if the workload is bursty, otherwise you may pass this check on average load but still exceed target utilization during the workload's actual peaks.