Docker CPU Limit Calculator
Recommend Docker CPU requests and limits from measured average and peak usage, and check they fit within host capacity.
Inputs
Average CPU usage observed per container under normal load.
Peak CPU usage observed per container during traffic spikes.
Number of containers of this profile running on the host(s).
Total vCPU cores available on the host running these containers.
Recommended CPU Request
360millicores
Recommended CPU Limit
1,200millicores
Limit Overcommit Ratio
1.50×
Max Containers (limits ≤ host)
6containers
Total Limits Exceed Host Capacity
true
Step by step
Recommended request: avg × 1.2
300m × 1.2
= 360m
Recommended limit: peak × 1.5
800m × 1.5
= 1200m
Total limit across containers
1200m × 10
= 12000m
Host capacity
8 cores
= 8000m
Limit overcommit ratio
12000 / 8000
= 1.50×
How it works
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.
Formulas
Recommended CPU request and limit
request = avg_cpu × 1.2; limit = peak_cpu × 1.5
- avg_cpu
- Measured average CPU usage in millicores
- peak_cpu
- Measured peak CPU usage in millicores
Limit overcommit ratio
overcommit_ratio = (limit × container_count) / (host_cores × 1000)
- limit
- Recommended CPU limit per container (millicores)
- container_count
- Number of containers on the host
- host_cores
- Total vCPU cores on the host
Frequently Asked Questions
Is it bad if total CPU limits exceed host capacity?
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.
Why 1.2× for requests and 1.5× for limits?
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.
What happens if a container exceeds its CPU limit?
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.
How should I measure 'peak' CPU accurately?
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.