Docker CPU Limit Calculator

Convert CPU shares, quotas and cores into the right Docker CPU limit settings.

About Docker CPU Limit Calculator

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

Worked example

With the default values below, Docker CPU Limit Calculator returns Recommended CPU Request of 360. Change any input above and every figure here is recalculated in your browser.

Inputs used

Measured Avg CPUaccepts 0–64,000 millicores: 300 millicores
Measured Peak CPUaccepts 0–64,000 millicores: 800 millicores
Number of Containersaccepts 1–100,000 containers: 10 containers
Host CPU Coresaccepts 0.1–512 cores: 8 cores

Results

Recommended CPU Request: 360 millicores
Recommended CPU Limit: 1,200 millicores
Limit Overcommit Ratio: 1.50 ×
Max Containers (limits ≤ host): 6 containers
Total Limits Exceed Host Capacity: true

Step by step

1Recommended request: avg × 1.2= 360m
2Recommended limit: peak × 1.5= 1200m
3Total limit across containers= 12000m
4Host capacity= 8000m
5Limit overcommit ratio= 1.50×

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

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.