How to Configure Linux cgroups v2 for Resource Isolation

The Noisy Neighbor Problem

In a standard Linux server, if you run a heavy database compilation script, that script will consume 100% of the CPU and all available RAM. If you are running a production web server on the exact same machine, the web server will be starved of resources and crash. This is the classic “noisy neighbor” problem.

To solve this, the Linux kernel provides Control Groups (cgroups). Cgroups allow system administrators to mathematically partition the CPU, RAM, and disk I/O, allocating strict hardware budgets to specific processes. While cgroups v1 was highly complex and disjointed (requiring different hierarchies for CPU vs. Memory), cgroups v2 completely overhauled the system into a single, unified, hierarchical tree, making it the modern standard for containerization engines like Docker and Kubernetes.

Step 1: Verifying cgroups v2 is Active

First, verify that your Linux distribution has booted with the unified cgroups v2 hierarchy.

mount | grep cgroup2

If the output shows cgroup2 on /sys/fs/cgroup type cgroup2, you are running v2. If it returns nothing, your system is still using legacy v1.

Step 2: Creating a Control Group

Unlike v1, where you used command-line tools like cgcreate, cgroups v2 is managed entirely by interacting with the virtual filesystem.

We will create a sandbox called restricted_app.

sudo mkdir /sys/fs/cgroup/restricted_app

The moment you create this directory, the Linux kernel instantly populates it with dozens of control files (e.g., cpu.max, memory.max, cgroup.procs).

Step 3: Enforcing Resource Limits

Now, we will enforce strict hardware limits on this specific cgroup.

1. Limiting CPU

The cpu.max file controls CPU bandwidth. The format is $MAX $PERIOD. If you want to limit the group to exactly 50% of a single CPU core, you allocate 50,000 microseconds out of every 100,000 microsecond period.

echo "50000 100000" | sudo tee /sys/fs/cgroup/restricted_app/cpu.max

2. Limiting RAM

The memory.max file sets a hard ceiling on physical RAM. If a process exceeds this, the kernel’s OOM (Out of Memory) killer will instantly terminate it.

To restrict the group to exactly 500 Megabytes of RAM:

echo "500M" | sudo tee /sys/fs/cgroup/restricted_app/memory.max

3. Disabling Swap

If a process hits its RAM limit, it might try to write to the hard drive (swap space) to stay alive. To force a hard kill instead, disable swap for this group.

echo "0" | sudo tee /sys/fs/cgroup/restricted_app/memory.swap.max

Step 4: Moving Processes into the Sandbox

The hardware cage is built, but it is currently empty. You must explicitly move a running Linux process (PID) into the cgroup.

Let’s say you have a rogue Python script running with Process ID (PID) 4599. To trap it in the sandbox, write its PID into the cgroup.procs file:

echo "4599" | sudo tee /sys/fs/cgroup/restricted_app/cgroup.procs

The moment you press Enter, the kernel instantly throttles PID 4599. If it was consuming 100% CPU, it will immediately drop to exactly 50%. If it attempts to allocate 501MB of RAM, the kernel will terminate it.

The Future of Linux Isolation

This virtual filesystem approach is incredibly powerful because it allows you to dynamically tune a live, running production server. You do not need to restart the application to change its hardware budget. If the Python script is running too slowly, you can simply echo 80000 100000 into the cpu.max file, and the kernel will instantly grant it 80% of the CPU core, completely eliminating the noisy neighbor threat.