Container CPU and memory limits

Container resource controls bound or prioritize a workload's CPU and memory use within a shared host rather than creating dedicated hardware.

A container can have resource controls that constrain its processes. CPU controls affect where or how much work is scheduled; memory controls affect the amount charged to the container's resource scope.

The host can still be shared. A limit does not manufacture dedicated physical processors or an independent supply of RAM.

CPU quota measures aggregate time

In a Linux-style bandwidth model, a quota is an amount of CPU time available during a period.

Quota: 200,000 microseconds of CPU time
Period: 100,000 microseconds of wall time
Average allowance: 200,000 / 100,000 = 2 CPU equivalents

Several threads can consume that allowance concurrently. On a host with four suitable execution resources, four fully busy threads could use the 200-ms aggregate budget in 50 ms, then wait for further budget under the declared scheduling model.

The “two CPU equivalents” result does not imply that exactly two physical cores are exclusively assigned. The real schedule also depends on host contention and controller rules.

Control What it expresses
CPU affinity/set Where the workload is eligible to run
CPU weight/shares Relative scheduling priority under contention
CPU quota A bandwidth ceiling over the specified accounting interval
Dedicated reservation, where supported A different allocation guarantee

Weights are not a universal rate guarantee. An idle competitor and a busy competitor produce different opportunities to use the host.

Memory is charged beyond one heap

A container's accounting can include application memory, native allocations, kernel-related charges and file cache. The managed-runtime heap is only part of that total.

Linux cgroup v2 distinguishes memory.high, which applies reclaim pressure and throttling behavior, from memory.max, a hard limit associated with allocation and out-of-memory handling. Docker's supported flags and the host implementation determine the resulting arrangement.

Observation What remains to check
Host has free RAM Container may still be near its own limit
Managed heap is small Native work and charged cache can be larger
Memory usage reaches a boundary Reclaim, stalls and allocation outcomes depend on the control
Process exits unexpectedly Logs and resource events are needed to attribute an OOM cause

An original 2,000-MB limit with 1,700 MB of active allocations and 500 MB of charged cache exceeds the limit by 200 MB. Reclaiming enough suitable cache can change the result; if active demand alone rises above the boundary, that route no longer supplies enough room.

Limits shape server deadlines

An Emby encoder that succeeds without a quota can lose real-time progress when available CPU time is capped. More encoder threads cannot bypass the aggregate ceiling.

Concurrent scans and playback also share the same container budget when charged together. A limit useful for containing a background workload can therefore affect foreground response if both use that scope.

Read the quota, accounting and pressure evidence alongside the media workload. A physical core count or host-wide graph alone cannot explain the resources available to the container.

See Also

References