Skip to content
cgroups: Memory Limits
step 1/5

Reading — step 1 of 5

Read

~1 min readcgroups & Resource Limits

cgroups: Memory Limits

While namespaces give containers their own view, cgroups give them their own resources.

cgroup (control group) is a kernel feature for grouping processes and applying limits. The classic v1 hierarchy is at /sys/fs/cgroup/:

/sys/fs/cgroup/memory/
  └── docker/
      ├── <container-id-1>/
      │     ├── tasks                 (PIDs in this group)
      │     ├── memory.limit_in_bytes (limit; e.g. 524288000 = 500 MB)
      │     └── memory.usage_in_bytes (current usage)
      └── <container-id-2>/...

Setting a limit: echo 524288000 > memory.limit_in_bytes. Adding a process: echo $PID > tasks.

When a process in the cgroup tries to allocate memory beyond the limit, the kernel triggers an OOM killer scoped to that cgroup. It picks a victim (heuristically, the biggest user) and SIGKILL's it. The container's other processes survive — only the offender dies.

Soft vs hard limits:

  • memory.limit_in_bytes — hard cap
  • memory.soft_limit_in_bytes — eviction threshold under contention; not strictly enforced

cgroup v2 (the modern hierarchy) uses a single unified tree under /sys/fs/cgroup/:

/sys/fs/cgroup/<group>/memory.max         (limit)
/sys/fs/cgroup/<group>/memory.current     (usage)
/sys/fs/cgroup/<group>/memory.swap.max    (swap limit)

Docker uses cgroups for: memory, CPU, blkio (disk I/O), pids (max processes), devices (which device files are accessible).

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Sign in to post a comment or reply.

Loading…