# Cgroups v2: Die Evolution der Ressourcensteuerung

TL;DR / Management Summary Während Cgroups v1 (Artikel 373) durch ihre Komplexität und Inkonsistenz bestach, räumt Cgroups v2 (Unified Hierarchy) radikal auf. Alle Ressourcen (CPU, RAM, I/O) werden nun in einem einzigen Verzeichnisbaum verwaltet. Dies ermöglicht eine deutlich präzisere Steuerung, echtes Ressourcen-Monitoring für alle Subsysteme gleichzeitig und eine tiefe Integration in systemd. Cgroups v2 ist der moderne Standard für Kubernetes, Podman und alle aktuellen SLES/Arch Versionen.

# 1. Einführung & Architektur

Ein Baum für alles.

In v2 gibt es keine getrennten Verzeichnisse für CPU und RAM mehr. Ein Prozess befindet sich in genau einer Gruppe, die alle seine Ressourcen kontrolliert.

# Das Unified-Modell (Mermaid)

graph TD
    A[Root: /sys/fs/cgroup/] --> B[Group: app.slice]
    B --> C[Subgroup: webserver]
    B --> D[Subgroup: database]
    C --> E[cgroup.controllers: cpu, memory, io]
    C --> F[cgroup.procs: PIDs]
    C --> G[memory.max: 1GB]
    C --> H[cpu.max: 200000 1000000]
    subgraph "The Single Writer"
        I[Systemd: The only Manager]
    end
    I --> B

# 2. systemd Integration: Slices und Scopes

Der moderne Weg der Konfiguration.

Admins manipulieren /sys/fs/cgroup/ in v2 fast nie manuell. Wir nutzen systemd Slices.

# Beispiel: Eine Slice für rechenintensive Jobs

Erstellen Sie /etc/systemd/system/workload.slice:

[Unit]
Description=Limited Workload Slice

[Slice]
CPUQuota=50%
MemoryMax=2G
IOWeight=50

Zuweisung in einem Dienst:

[Service]
Slice=workload.slice

# 3. Direkte Steuerung via CLI

Schnelle Limits ohne Unit-Files.

Nutzen Sie systemd-run, um einen Befehl sofort in einer limitierten Gruppe zu starten:

# Startet eine Shell mit max. 512MB RAM
systemd-run --user --scope -p MemoryMax=512M /bin/bash

# 4. Day-2 Operations: Druck-Monitoring (PSI)

Wann bricht das System ein?

Cgroups v2 ist eng mit PSI (Pressure Stall Information) verzahnt (siehe Artikel 216).

# Zeige Druck auf CPU in einer spezifischen Gruppe
cat /sys/fs/cgroup/app.slice/cpu.pressure

Dies erlaubt es zu erkennen, ob ein Prozess innerhalb seiner Gruppe “verhungert”, auch wenn der Gesamt-Host noch Ressourcen frei hat.

# 5. Troubleshooting & “War Stories”

Wenn der Mischbetrieb scheitert.

# Story 1: “Die verschwundenen v1 Controller”

Symptom: Ein altes Monitoring-Tool oder eine alte Docker-Version findet keine CPU-Stats mehr unter /sys/fs/cgroup/cpu/. Ursache: Das System wurde auf den reinen Unified Mode (v2) umgestellt. Die v1-Hierarchien sind weg. Lösung: Stellen Sie sicher, dass Ihre Tools v2-kompatibel sind. Falls zwingend nötig, können Sie via Boot-Parameter systemd.unified_cgroup_hierarchy=0 zum alten Modell zurückkehren (nicht empfohlen für neue Systeme!).

# Story 2: “Das Root-Restriction Problem”

Symptom: Ein Admin versucht ein Limit für eine Untergruppe zu setzen, bekommt aber Permission Denied, obwohl er Root ist. Ursache: In v2 gilt die “No Internal Process” Regel. Eine Gruppe darf nur dann Ressourcen an ihre Kinder verteilen, wenn sie selbst keine eigenen Prozesse (PIDs) enthält (außer im Root). Lösung: Verschieben Sie alle Prozesse in die Blatt-Knoten (Leaf nodes) des Baums.

# 6. Fazit & Empfehlung

• Standard: Nutzen Sie für SLES 15 SP4+ und Arch ausschließlich Cgroups v2.
• Wartung: Nutzen Sie systemd-cgtop, um eine Echtzeit-Ansicht Ihrer Slices zu erhalten.
• Performance: v2 ist durch den Wegfall der mehrfachen Hierarchie-Synchronisation deutlich CPU-effizienter als v1.

# Anhang: Cheatsheet