A fractional CPU limit
Exactly a quota and a period, and the window is what causes throttling
--cpus=1.5
Convert between the CPU flags and see what each one actually enforces. Two of them are not limits at all, and one of them throttles work that averages well below its ceiling.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Exactly a quota and a period, and the window is what causes throttling
--cpus=1.5
A weight rather than a limit, so nothing caps this container at all
--cpu-shares=512
Caps usage only as a side effect, and fails to start on a smaller host
--cpuset-cpus=0-3
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It is a relative weight that only applies under contention. On an idle host the container uses everything, so the limit you thought you set does not exist.
Instead:Use --cpus for a ceiling. Keep shares for expressing priority between containers that genuinely compete.
If the cause is quota throttling on a bursty workload, more quota helps only until the burst grows. The stall is caused by the window, not by the total.
Instead:Check nr_throttled in cpu.stat first. A shorter --cpu-period reduces the size of each stall.
Most runtimes read the host's core count, so a one-CPU container starts as many workers as the host has cores and they all contend for one core's quota.
Instead:Set GOMAXPROCS, UV_THREADPOOL_SIZE and equivalent limits explicitly from the container's CPU limit.
--cpus=1.5 sets --cpu-quota=150000 with --cpu-period=100000: 150ms of CPU in every 100ms window. That is enforced per window, not on average.
Once a container has spent its quota for the current 100ms period it is stopped until the next one starts. A process idle for 80ms then wanting four cores for 20ms is throttled hard, while its average usage sits comfortably under the limit. The symptom is latency spikes with flat CPU graphs, and the evidence is nr_throttled in the cgroup's cpu.stat.
It ties the container to named cores, so it caps usage only as a side effect of how many you named. It is also not portable: a cpuset naming core 8 fails to start on a four-core host, which is how an image that works on one machine does not on another.
The period defaults to 100000 microseconds. Somebody who sets --cpu-quota=50000 thinking in milliseconds gets half a CPU rather than the fifty they had in mind, or the other way round. Using --cpus avoids the arithmetic entirely.
A quota does not change what /proc/cpuinfo reports. Modern JVMs read the cgroup; Node's libuv pool, Go before 1.25, and most thread-pool defaults do not. A container limited to one CPU on a 64-core host starts 64 workers that then fight over one core's quota.
limits.cpu is the quota; requests.cpu is the share weight. So a Kubernetes pod with a request and no limit is the --cpu-shares situation, with all the same testing problems.