Linux Kernel cgroups v2: How Modern Multi-Tenant Web Hosting Isolates CPU & Memory

In shared hosting and containerized environments, the "noisy neighbor" problem has historically been the primary cause of server instability. When a single tenant runs a runaway SQL query or falls victim to an XML-RPC brute force flood, unconstrained resource consumption can quickly starve neighboring accounts. The transition from cgroups v1 to cgroups v2 (unified hierarchy) in modern Linux distributions provides systems administrators with granular, deterministic resource boundaries.

The Architectural Flaw of cgroups v1

In the legacy v1 architecture, each subsystem operated independently:

Memory Controller: Tracked anonymous and page cache allocations.
BlkIO Controller: Tracked block device I/O requests.

Because the controllers were uncoordinated, buffered write operations were attributed to the kernel's background writeback threads rather than the originating cgroup. A rogue PHP script writing gigabytes to disk could monopolize NVMe write queues without being throttled by blkio.weight.

cgroups v1 (Fragmented):
/sys/fs/cgroup/memory/user-1001/
/sys/fs/cgroup/cpu/user-1001/
/sys/fs/cgroup/blkio/user-1001/  &lt;-- No coordination between memory & I/O

cgroups v2 (Unified):
/sys/fs/cgroup/hosting.slice/user-1001/
  ├── cgroup.controllers (cpu memory io pids)
  ├── memory.max
  ├── io.weight
  └── cpu.weight

1. Unified Hierarchy and Memory Writeback

cgroups v2 resolves this by enforcing a single hierarchy. When a process inside a cgroup generates dirty pages, the kernel's memory management subsystem accurately credits those pages to the cgroup. When the writeback occurs, the io controller throttles the specific cgroup rather than slowing down other tenants. Key controllers in production include:

Attribute	Function	Hosting Use Case
`memory.min`	Hard memory reservation (never reclaimed)	Protect system-critical services (SSH, DNS)
`memory.low`	Soft memory protection (reclaimed only under pressure)	Prevent cold-start latency on active tenant pools
`memory.high`	Throttle limit before hard OOM	Gently slows down misbehaving PHP workers
`memory.max`	Hard limit (OOM killer invoked if breached)	Prevents runaway memory leaks

2. Implementing Systemd Slices for Web Hosting

For administrators managing Linux web servers, creating dedicated systemd slices provides a reliable mechanism to isolate user worker pools without manual script orchestration:

# /etc/systemd/system/hosting-user.slice
[Unit]
Description=Isolated Slice for Hosting Tenant
DefaultDependencies=no

[Slice]
CPUAccounting=yes
MemoryAccounting=yes
IOAccounting=yes

# Limits
CPUQuota=200%
MemoryHigh=1024M
MemoryMax=1536M
IOWeight=100
TasksMax=256

Reload systemd and assign user units to the slice:

systemctl daemon-reload
systemctl set-property hosting-user.slice MemoryHigh=1024M MemoryMax=1536M

Summary for Systems Administrators

By adopting cgroups v2 and monitoring Pressure Stall Information (/proc/pressure/), infrastructure teams can guarantee sub-millisecond response times for stable tenants while automatically throttling resource spikes before they escalate into node-wide outages.