Operations 23 min read

How to Use Linux cgroups to Prevent Process Memory Overflows

The article explains why process memory overflows are a critical issue in server operations and provides a step‑by‑step guide on using Linux cgroups to set precise memory limits, monitor usage, and avoid OOM crashes, illustrated with real‑world examples and troubleshooting tips.

Deepin Linux
Deepin Linux
Deepin Linux
How to Use Linux cgroups to Prevent Process Memory Overflows

1. cgroup Memory Control Mechanism

1.1 What is cgroup

cgroup (control groups) is a Linux kernel feature that groups processes and limits their use of physical resources such as CPU, memory, and I/O. When a process exceeds the configured memory.max, the OOM killer terminates it; CPU limits cause the process to wait for the next scheduling slice.

1.2 Functions and Scenarios

The memory subsystem can set a strict usage ceiling for a group. Once the limit is reached, further allocation triggers OOM, preventing a single group from exhausting system memory. The CPU subsystem can assign higher cpu.share values to high‑priority services (e.g., financial transaction processors) to guarantee CPU time.

The cpuacct subsystem records per‑group CPU usage, providing a detailed consumption report for administrators.

cgroups are also the core isolation mechanism for containers and multi‑user systems, allowing each container or user group to have independent resource quotas.

1.3 Working Principle

cgroup consists of three concepts: hierarchy, subsystem, and control group. The hierarchy is a tree of groups; each child inherits limits from its parent but can impose stricter constraints. Subsystems (e.g., cpu, memory) manage specific resources. A control group is a set of processes that share the same limits.

2. Underlying Logic of cgroup Memory Limits

2.1 Key Components and Data Structures

The Memory Controller is the core component. It uses the mem_cgroup structure to track current usage, peak usage, and per‑process associations.

2.2 Implementation and Algorithm

Setting memory.limit_in_bytes defines a hard “red line” for a group. The kernel monitors allocations; if the current usage approaches the limit, it may allow a small over‑run when overall system memory is abundant, otherwise it denies the allocation and may invoke the OOM killer.

2.3 Coordination with Other Kernel Modules

The memory manager checks cgroup limits before granting pages. The scheduler lowers the CPU priority of groups that are near their memory limit, reducing further memory pressure.

3. Using cgroup to Control Process Memory

3.1 Preparation

Verify kernel support with cat /proc/cgroups and ensure the cgroup filesystem is mounted at /sys/fs/cgroup/memory. If not, mount it:

mount -t cgroup -o memory none /sys/fs/cgroup/memory

3.2 Create a cgroup and Set a Limit

Example: create a group mygroup and limit it to 100 MB.

sudo mkdir /sys/fs/cgroup/memory/mygroup
 echo "100M" | sudo tee /sys/fs/cgroup/memory/mygroup/memory.limit_in_bytes

3.3 Add a Process to the cgroup

Write the target PID to the group's tasks file:

echo "12345" | sudo tee /sys/fs/cgroup/memory/mygroup/tasks

3.4 Monitor Memory Usage

Check current usage:

cat /sys/fs/cgroup/memory/mygroup/memory.usage_in_bytes

View detailed statistics:

cat /sys/fs/cgroup/memory/mygroup/memory.stat

4. Practical Case: Solving a Web‑Server Memory Overflow

4.1 Scenario

A busy forum backend process ( forum-backend) repeatedly consumes memory, causing the server to swap and eventually crash.

Investigation with top, gdb, and valgrind revealed memory leaks in the image‑upload handling code.

4.2 Applying cgroup

Create a dedicated cgroup and limit it to 512 MB:

sudo mkdir /sys/fs/cgroup/memory/forum-backend-group
 echo "512M" | sudo tee /sys/fs/cgroup/memory/forum-backend-group/memory.limit_in_bytes
 echo "5678" | sudo tee /sys/fs/cgroup/memory/forum-backend-group/tasks

After the limit is applied, the process cannot exceed 512 MB; attempts to allocate more trigger the OOM mechanism, preventing a full‑system outage. Although the leak remains, the server stays stable and user‑experience improves.

4.3 Common Issues and Fixes

(1) Limit not taking effect – Ensure the kernel has CONFIG_MEMCG=y, the memory subsystem is correctly mounted, and the target PID is written to tasks.

(2) Process killed before reaching the limit – The combined memory + swap limit ( memory.memsw.limit_in_bytes) may be lower. Adjust it and optionally set memory.swappiness to control swap usage.

Example adjustments:

echo "1G" | sudo tee /sys/fs/cgroup/memory/mygroup/memory.limit_in_bytes
 echo "1536M" | sudo tee /sys/fs/cgroup/memory/mygroup/memory.memsw.limit_in_bytes
 echo "10" | sudo tee /sys/fs/cgroup/memory/mygroup/memory.swappiness

These configurations ensure the process is limited without unexpected termination.

Overall, cgroup’s hierarchical management, precise accounting, strict limits, and integration with the kernel’s memory manager and scheduler provide a robust solution for preventing process memory overflows in multi‑process Linux environments.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

memory managementLinuxsystem administrationOOM killercgroupprocess isolation
Deepin Linux
Written by

Deepin Linux

Research areas: Windows & Linux platforms, C/C++ backend development, embedded systems and Linux kernel, etc.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.