CPU Capacity Planner
Plan CPU capacity needs for future growth based on current utilization trends.
About CPU Capacity Planner
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
Worked example
With the default values below, CPU Capacity Planner returns Headroom (core-equivalent) of 4.00. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Current CPU Utilization (%)accepts 0–100
- 45
- Target Max Utilization (%)accepts 1–100
- 70
- CPU Coresminimum 1
- 16
- New Workload's Estimated Core Demandminimum 0
- 3
Results
- 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
- 1Values used
- 2Headroom and fit check
- 3Headroom (core-equivalent)= 4.00
- 4Verdict= Fits — projected utilization after adding the workload is 63.8%, within the 70% target.
- 5Projected Utilization After New Workload= 63.75
- 6New Workload Fits?= Yes
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.