Skip to main content
Containers and the Docker host share the same kernel and, by extension, the host’s hardware resources such as CPU and memory. Without explicit restrictions, a container can consume as much of those shared resources as the host allows, potentially impacting other containers and the host itself. Docker relies on cgroups (control groups) to control how much CPU and memory a container may use. cgroups provide mechanisms to limit, account for, and isolate resource usage (CPU, memory, block I/O, etc.) for a set of processes — in this case, the container processes.
An infographic titled "cgroups · resource limits" showing two panels — an orange "without cgroups" card and a green "with cgroups" card — each displaying CPU and RAM progress bars marked at 100%.

​
Common docker run flags that use cgroups

You set cgroup-backed limits when creating a container with docker run. The most common flags control CPU and memory:
Use --cpus and --memory for most common resource constraints. For advanced tuning (e.g., real-time workloads or strict core pinning), consider --cpuset-cpus, --cpu-quota/--cpu-period, and --memory-swap. Monitor usage with docker stats to validate limits in production.

​
Examples

Limit CPU and memory when starting a container:
More explicit CPU quota/period example (equivalent to ~0.5 CPUs if period is 100000 microseconds and quota is 50000):
Pin a container to specific CPU cores:
Control memory plus swap:
If a container exceeds its memory limit, the kernel may kill processes inside the container (OOM). Always set sensible limits for your workload, test them under load, and monitor containers with docker stats and your observability tools.

​
Quick reference and resources

For more on Docker resource management and production tuning, consult the Docker documentation and your orchestration platform’s resource management guides.

Watch Video