# Proxmox Resource Limits: cgroups, CPU-Units & I/O Throttling

TL;DR / Management Summary In einer geteilten Umgebung (Shared Infrastructure) ist die gerechte Ressourcenverteilung entscheidend. Proxmox nutzt im Hintergrund die Linux cgroups (Control Groups) Technologie, um CPU, RAM und I/O für Container und VMs zu limitieren. Ein Senior Admin nutzt diese “Leitplanken”, um sicherzustellen, dass eine Amok-laufende Test-VM nicht das gesamte Rechenzentrum lahmlegt. Wir unterscheiden dabei zwischen harten Limits (Absolute Obergrenze) und weichen Limits (CPU-Units zur relativen Gewichtung).

# 1. Einführung: Was sind cgroups?

Die Polizisten des Kernels.

cgroups erlauben es dem Linux-Kernel, Ressourcen hierarchisch zu gruppieren und einzuschränken.

• cgroup v1: Der alte Standard (getrennte Hierarchien).
• cgroup v2 (Standard ab PVE 7): Eine einzige, vereinheitlichte Hierarchie. Bietet besseres Ressourcen-Tracking und präziseres Throttling.

# 2. CPU-Limitierung in der Praxis

Kerne vs. Anteile.

# 1. CPU Cores (Harte Grenze)

• Einstellung: VM -> Hardware -> CPU -> Cores.
• Wirkung: Die VM/LXC kann physisch nicht mehr als z.B. 4 Kerne gleichzeitig nutzen.

# 2. CPU Units (Relative Gewichtung)

• Einstellung: CPU -> Edit -> CPU units. (Standard: 1024).
• Logik: Wenn der Host unter Volllast steht, bekommt ein Container mit 2048 Units doppelt so viel Rechenzeit wie einer mit 1024.
• Vorteil: Im Leerlauf darf jeder alles nutzen, erst bei Stress wird die Priorität erzwungen.

# 3. Deep Dive: I/O Throttling

Den Schreibstau verhindern.

Ein Backup-Job oder ein Datenbank-Import kann den ZFS-Pool (Artikel 683) sättigen.

• Limit-Typen:
  • Bandwidth (MB/s): Max. Durchsatz.
  • IOPS (Read/Write): Max. Anzahl an Befehlen pro Sekunde.
• Aktion: Setzen Sie für alle unkritischen VMs ein Limit von z.B. 100 MB/s und 500 IOPS.

# 4. Day-2 Operations: Memory Limits (RSS)

Den OOM-Killer steuern.

In LXC-Containern ist das RAM-Management besonders kritisch.

• RAM: Das Limit für physischen Arbeitsspeicher.
• Swap: Wenn der RAM voll ist, wird auf die Disk geschrieben.
• Empfehlung: Setzen Sie den Swap für Performance-Workloads auf 0, damit der Prozess lieber abstürzt (und Sie alarmiert werden), als den gesamten Host durch massives Paging zu verlangsamen.

# 5. Troubleshooting & “War Stories”

Wenn die Schranke zu eng ist.

# Top 3 Fehlerbilder

1. Symptom: Applikation im Container ist langsam, obwohl CPU bei 10% liegt.

   • Ursache: Das I/O-Limit wurde erreicht. Der Prozess hängt im Status D (Uninterruptible Sleep).
   • Lösung: pct status <id> prüfen und Limits temporär anheben.

2. Symptom: Host-Reboot während LXC-Start.

   • Ursache: Zu viele Inodes oder offene Files in den cgroups.
   • Fix: /etc/security/limits.conf am Host anpassen (Artikel 707).

3. Symptom: CPU-Units werden ignoriert.

   • Ursache: Der Host hat noch freie CPU-Zyklen. cgroups greifen nur bei Ressourcen-Konflikten.

# “War Story”: Der “Zufalls”-Crash beim Backup

Ein Admin betrieb einen Cluster ohne I/O-Limits. Jeden Sonntag um 3:00 Uhr stürzte die Telefonanlage (LXC) ab. Die Ursache: Das wöchentliche Full-Backup eines riesigen Fileservers auf dem gleichen Host beanspruchte 100% der ZFS-I/O-Warteschlange. Der Heartbeat der Telefonanlage (Realtime-Anforderung) lief in einen Timeout, und der Prozess wurde vom Watchdog beendet. Lösung: Wir setzten ein I/O Throttle von 200 MB/s für den Fileserver. Das Backup dauerte nun zwar 30 Minuten länger, aber die Telefonanlage lief stabil durch. Lehre: Harte Limits für “Elefanten-Workloads” schützen die “Maus-Workloads” (Latenz-kritisch).

# 6. Monitoring & Reporting

cgroup Statistiken.

# Die cgroup-Hierarchie am Host (Shell)

# Zeigt die aktuelle Auslastung der cgroups
systemd-cgtop

• KPI: Suchen Sie nach dem Pfad pve.slice. Hier sehen Sie alle VMs und deren Echtzeit-CPU/RAM-Verbrauch auf Kernel-Ebene.

# 7. Fazit & Empfehlung

Ressourcen-Limits sind das soziale Schmiermittel des Clusters.

• Empfehlung: Nutzen Sie CPU Units zur Priorisierung von Kern-Diensten (AD, DNS).
• Wichtig: Verwenden Sie I/O Throttling für alle VMs mit großen Datenmengen (Backups, Archiv-Server), um die Storage-Latenz für alle anderen Mieter stabil zu halten.

# Anhang: Cheatsheet (pct set limits)

# Referenzen

• Proxmox VE: Resource Control Group v2
• Linux Kernel: Documentation/cgroup-v2
• Performance comparison of cgroup v1 vs v2