Ressourcenlimits und cgroups

Die wichtigsten Befehle zum Merken

• systemd-run --user — einen temporären Benutzerdienst erzeugen.
• systemctl --user show — konfigurierte Ressourceneigenschaften prüfen.
• systemctl --user stop — den Testdienst beenden.

Befehle und Optionen

Befehl oder Option	Bedeutung
--user	Den eigenen statt des systemweiten Service-Managers nutzen.
--unit=btc-cgroup-lab --collect	Testunit benennen und nach Ende, auch Fehler, entladen.
--property=CPUQuota=20%	Bis zu 20% der Zeit einer CPU über den Quotenzeitraum erlauben.
--property=MemoryMax=64M	Speichergrenze von 64 MiB setzen; Swap wird separat geregelt.
--property=TasksMax=16	Höchstens sechzehn Tasks einschließlich Threads erlauben.
sleep 120	Einen harmlosen Prozess höchstens 120 Sekunden halten.
show … -p EIGENSCHAFT	Nur ausgewählte Eigenschaften zeigen.
stop btc-cgroup-lab.service	Den Beispieldienst beenden.

Die entscheidenden Konzepte

1. Eine cgroup rechnet eine Prozessgruppe ab

Eine Control Group, kurz cgroup, organisiert Prozesse zur Ressourcenabrechnung und Begrenzung. Controller steuern etwa CPU, Speicher und Taskzahl. Kindprozesse bleiben grundsätzlich in der betreffenden Gruppenhierarchie, sofern sie nicht verschoben werden.

Das ergänzt Namespaces: Isolierte Sicht kann ohne Verbrauchslimit bestehen, gemeinsame Sicht mit strengem Budget. Sichtbarkeit und Verbrauch sind verschiedene Kontrollen.

2. CPU-Quote ist ein Zeitbudget

Eine CPU-Quote begrenzt Rechenzeit über einen Zeitraum. 20% bedeutet ein Fünftel einer CPU, nicht jeder CPU des Rechners. Werte über 100% erlauben insgesamt Arbeit auf mehreren CPUs.

Die Quote bindet nicht an einen bestimmten Kern und garantiert keine Latenz. Nach Budgetverbrauch kann Drosselung lauffähige Arbeit verzögern. CPU-Gewicht beschreibt dagegen relative Anteile bei Konkurrenz statt einer festen Obergrenze.

3. Speicher- und Tasklimits wirken unterschiedlich

Eine Speichergrenze kann Rückgewinnung und bei nicht einhaltbarem Budget eine Out-of-Memory-Reaktion auslösen. Sie bittet die Anwendung nicht einfach um langsamere Arbeit.

Ein Tasklimit betrifft Prozesse und Threads. Bei Erreichen kann neue Taskerzeugung trotz freien Speichers scheitern. Unterscheide Speicherfehler, fehlgeschlagene Threaderzeugung und CPU-Drosselung. Das falsche Limit zu erhöhen behebt keine Ursache.

4. Die Hierarchie begrenzt das wirksame Budget

cgroup v2 organisiert Gruppen hierarchisch. Elternbeschränkungen gelten auch für Nachkommen; eine großzügige Kindeinstellung überstimmt keine engere wirksame Elterngrenze.

Service-Manager und Container-Runtimes übersetzen Einstellungen in diese Struktur. Prüfe die tatsächliche Gruppe und ihren Kontext statt allein das angeforderte Budget. Konfigurationsansicht und gemessener Belastungstest beantworten unterschiedliche Fragen.

Ein kleines Beispiel

Optional: Nutze dein normales Konto mit den genannten delegierten Controllern. Stoppe bei vorhandenem Unitnamen oder Erstellungsfehler. Prüfe die Unit vor Ablauf der 120 Sekunden.

systemd-run --user --unit=btc-cgroup-lab --collect --property=CPUQuota=20% --property=MemoryMax=64M --property=TasksMax=16 sleep 120
systemctl --user show btc-cgroup-lab.service -p ControlGroup -p CPUQuotaPerSecUSec -p MemoryMax -p TasksMax
systemctl --user stop btc-cgroup-lab.service

ControlGroup nennt den cgroup-Pfad. MemoryMax sollte 67108864 Bytes, TasksMax sechzehn darstellen. CPUQuotaPerSecUSec kann als Dauer entsprechend 200 Millisekunden CPU-Zeit pro Sekunde Kapazität erscheinen.

Der Sleeper verbraucht kaum Ressourcen; geprüft wird Konfiguration, keine Drosselung oder OOM-Reaktion. Stop beendet ihn, collect entfernt die temporäre Unit. Nach bereits erfolgtem Ende kann die Unit fehlen. Eine dauerhafte Unitdatei entsteht nicht.

Merke dir: Cgroups begrenzen Gruppenverbrauch. Wirksame Budgets hängen auch von Elternregeln und Controllerunterstützung ab.