Plan CPU capacity needs for future growth based on current utilization trends.
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.
Headroom and fit check
headroom = (target_util% − current_util%) / 100 × cores; fits if new_workload_cores ≤ headroom
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.
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.
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.