Mastering Linux Cgroups: Control Resources for Containers and Services

1. Why Learn Cgroups

Since Docker (2013) and Kubernetes (2014) popularized cloud‑native technologies, containers have become mainstream, and they rely on Linux kernel features like Cgroups and Namespaces to enforce resource limits and isolation.

Cgroups mainly manage resource allocation and limits; Namespace mainly provides isolation so that processes in a namespace have their own global resources.

2. Cgroups Overview

Cgroups (control groups) is a Linux kernel mechanism that can limit, record, and isolate the physical resources (CPU, memory, I/O, etc.) used by a group of processes, forming the foundation for Docker and other container‑management tools.

Using Cgroups, administrators can finely control resource allocation, scheduling, denial, monitoring, and improve overall system efficiency. Originally proposed by Google engineers, Cgroups are now a core component of lightweight virtualization technologies such as Linux Containers (LXC).

3. What Is Cgroups?

Cgroups (short for control groups) allow the Linux kernel to limit, record, and isolate the resources used by a process group.

Cgroups consist of two main parts:

subsystem : a kernel module attached to a cgroup hierarchy that performs specific resource control (e.g., CPU, memory). Linux currently supports 12 subsystems.

hierarchy : a cgroup tree; each node is a process group, and a hierarchy can be associated with multiple subsystems.

4. Why Need Cgroups?

Linux has long supported process grouping (session groups, process groups, etc.). As demands grew—such as tracking memory and I/O usage—Cgroups were introduced to provide unified grouping, monitoring, and resource control.

Examples: antivirus software consuming excessive resources, a Docker container hogging CPU, or a Java process exhausting memory can be limited using Cgroups.

5. How Cgroups Are Implemented

On CentOS 7 / RHEL 7, Cgroup hierarchies are bound to systemd unit trees, moving resource management from individual processes to applications. systemd automatically creates slice, scope, and service units, forming a three‑level hierarchy: system.slice, user.slice, and machine.slice.

CPU resources are divided among the three top‑level slices. If user.slice needs 100 % CPU while the CPU is idle, it receives the full share. The three slices are:

system.slice : default location for all system services.

user.slice : default location for all user sessions; each user gets a sub‑slice.

machine.slice : default location for virtual machines and containers.

6. Functions of Cgroups

Cgroups provide a unified framework for resource management, integrating existing subsystems and offering interfaces for future extensions. Their main functions are:

Resource limiting (e.g., memory limits trigger OOM).

Prioritization (e.g., CPU shares).

Accounting (e.g., cpuacct records CPU time).

Isolation (e.g., ns subsystem isolates namespaces).

Control (e.g., freezer can suspend/resume a group).

7. Concepts and Relationships

7.1 Concepts

Task : a single process in Cgroups.

Control group : a set of processes grouped by a common criterion; resources are managed per control group.

Hierarchy : a tree of control groups; child groups inherit attributes from their parent.

Subsystem : a resource controller (e.g., cpu, memory) that must be attached to a hierarchy to take effect.

7.2 Relationships

When a new hierarchy is created, all tasks belong to the root cgroup of that hierarchy.

A subsystem can be attached to only one hierarchy.

A hierarchy may have multiple subsystems.

A task can belong to multiple cgroups, provided they are in different hierarchies.

Child processes inherit their parent’s cgroup membership.

8. Subsystem Introduction

Under /sys/fs/cgroup you can see directories such as cpu and memory, each representing a subsystem.

Common subsystems include:

net_cls : tags packets for traffic control.

net_prio : sets network traffic priority.

memory : controls memory usage.

cpuset : assigns specific CPUs and memory nodes.

freezer : suspends and resumes tasks.

blkio : limits block‑device I/O.

cpu : controls CPU time.

cpuacct : reports CPU usage.

devices : controls device access.

8.1 How to View Supported Subsystems

Check /proc/cgroups to see which subsystems are enabled:

#subsys_name hierarchy num_cgroups enabled
cpuset 11 1 1
cpu 3 64 1
cpuacct 3 64 1
blkio 8 64 1
memory 9 104 1
devices 5 64 1
freezer 10 4 1
net_cls 6 1 1
perf_event 7 1 1
net_prio 6 1 1
hugetlb 4 1 1
pids 2 68 1

8.2 CPU Subsystem Details

The CPU subsystem uses five interfaces: cpu.cfs_period_us: period of CPU bandwidth in microseconds. cpu.cfs_quota_us: allowed CPU time within the period (‑1 means unlimited). cpu.shares: relative weight for CPU time allocation. cpu.rt_runtime_us: maximum continuous CPU time for real‑time tasks. cpu.rt_period_us: period for real‑time CPU allocation.

8.3 Installing Cgroups on CentOS

# Install if not present
yum install libcgroup
# Check status and start service
service cgconfig status
service cgconfig start
# Verify cgroup support
grep cgroup /proc/filesystems

9. Using Cgroups

9.1 Setting Cgroup via systemctl

Use systemctl set-property to configure slices, services, or scopes. Focus on Block, CPU, and Memory properties.

# Example: limit CPU for user‑1000.slice to 20%
systemctl set-property user-1000.slice CPUQuota=20%

9.2 Viewing Cgroup via systemd

List the hierarchy with systemd-cgls and view resource usage with systemd-cgtop.

$ systemd-cgls --no-page
$ systemd-cgtop

9.3 Inspecting Cgroup via /proc

Read /proc/[pid]/cgroup to see a process’s cgroup memberships.

$ cat /proc/777/cgroup
11:cpuset:/
10:freezer:/
9:memory:/system.slice/cron.service
...

9.4 Inspecting Cgroup via /sys

Check CPU limits directly:

$ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user-1000.slice/cpu.cfs_period_us
100000
$ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user-1000.slice/cpu.cfs_quota_us
20000

This means the user can use 20 ms of CPU every 100 ms, regardless of CPU idleness.