Convert CPU shares, quotas and cores into the right Docker CPU limit settings.
A safe CPU request should absorb normal usage with margin (avg × 1.2), while the limit should cover observed peaks with headroom for unexpected spikes (peak × 1.5) without starving neighboring containers. Formula: request = avg_cpu × 1.2; limit = peak_cpu × 1.5. Because Docker/Kubernetes allow limits to be overcommitted relative to host capacity (since not all containers peak simultaneously), this calculator flags when your total limits exceed host CPU so you can consciously decide on an overcommit ratio rather than discover it during an incident.
Recommended CPU request and limit
request = avg_cpu × 1.2; limit = peak_cpu × 1.5
Limit overcommit ratio
overcommit_ratio = (limit × container_count) / (host_cores × 1000)
Not necessarily — CPU limit overcommit is common and expected, since containers rarely all hit their peak simultaneously. It becomes a problem only if enough containers peak at once that the host runs out of CPU, causing throttling across the board.
These are conservative planning multipliers: 1.2× on average usage gives modest headroom for the scheduler's request-based bin-packing, while 1.5× on peak usage allows for spikes beyond what you've already measured as 'peak' without immediately hitting CPU throttling.
Unlike memory, CPU is a compressible resource — the container is throttled (its CPU time is capped) rather than killed, which shows up as increased latency rather than an OOMKill-style crash.
Use a monitoring window that captures your real traffic patterns (e.g. p99 or max over a week including your highest-traffic events), not just a short synthetic load test, since transient spikes during deploys or batch jobs are often the true peak.