Systemd Baustein Ressourcen
Zur Navigation springen
Zur Suche springen
| Baustein | ab Stufe | Lernpfad |
|---|---|---|
| Ressourcen und cgroups | Stufe 2 | Übersicht |
Einfach erklärt
- Jeder Dienst steckt in einer eigenen cgroup (Control Group). Das ist eine Schublade des Kernels für Prozesse.
- Über diese Schublade weiß systemd immer, welche Prozesse zu welchem Dienst gehören, auch wenn sie sich vervielfältigen.
- Für jede Schublade kann man Grenzen setzen: höchstens so viel Speicher, so viel CPU, so viele Prozesse.
- Schubladen werden in Slices gruppiert. Grenzen an einer Slice gelten für alles darin zusammen.
Der Baum
-.slice die Wurzel ├─ system.slice alle Dienste │ ├─ ssh.service │ └─ cron.service ├─ user.slice alle angemeldeten Benutzer │ └─ user-1000.slice │ └─ session-2.scope └─ machine.slice Container und VMs, siehe [[Systemd Baustein Container]]
- Service: von systemd gestartet. Scope: Prozesse, die schon laufen und nur einsortiert werden, z.B. eine Anmeldung.
Anzeigen
| Befehl | Wirkung |
|---|---|
| systemd-cgls | der ganze Baum mit allen Prozessen |
| systemd-cgls -u ssh.service | nur ein Dienst |
| systemd-cgtop | wie top, aber pro cgroup: CPU, Speicher, Prozesse |
| systemctl status ssh | im Abschnitt CGroup stehen alle Prozesse des Dienstes |
| systemctl show ssh -p MemoryCurrent -p CPUUsageNSec -p TasksCurrent | Verbrauch eines Dienstes als Zahl |
Grenzen setzen
| Option | Wirkung |
|---|---|
| MemoryMax=500M | harte Grenze. Darüber beendet der Kernel Prozesse des Dienstes (OOM) |
| MemoryHigh=400M | weiche Grenze. Darüber wird der Dienst gebremst |
| CPUQuota=30% | höchstens 30 % eines CPU-Kerns, 200 % = zwei Kerne |
| CPUWeight=50 | Anteil, wenn es eng wird. Standard 100, weniger = bescheidener |
| TasksMax=100 | höchstens 100 Prozesse und Threads, schützt vor Fork-Bomben |
| IOWeight=50 | Anteil an der Platte, wenn es eng wird |
In der Unit
- systemctl edit dienst
[Service] MemoryMax=500M CPUQuota=30% TasksMax=100
Im laufenden Betrieb
- systemctl set-property dienst CPUQuota=30%
- Wirkt sofort und bleibt nach dem Neustart. Die Datei landet unter /etc/systemd/system.control/, die bearbeitet man nicht von Hand.
- Nur bis zum Neustart: systemctl set-property --runtime dienst CPUQuota=30%
Eine eigene Slice
- /etc/systemd/system/batch.slice
[Slice] CPUQuota=50% MemoryMax=1G
- Dienste einsortieren: Slice=batch.slice im [Service]-Teil. Alle Dienste darin teilen sich zusammen 50 % CPU und 1 GB.
Einen Befehl begrenzt starten
- systemd-run --scope -p CPUQuota=20% -p MemoryMax=200M ./rechnen.sh
- Gut zum Ausprobieren: Man sieht sofort in systemd-cgtop, wie die Grenze wirkt.
Beispiel: Last erzeugen und bremsen
systemd-run --unit=last -p CPUQuota=100% /usr/bin/sha256sum /dev/zero systemd-cgtop systemctl set-property --runtime last.service CPUQuota=20% systemd-cgtop systemctl stop last.service
- In systemd-cgtop fällt die CPU von last.service von 100 % auf 20 %.
Stolperfallen
- MemoryMax= zu klein: Der Dienst wird vom Kernel beendet. Im Journal steht A process of this unit has been killed by the OOM killer.
- CPUQuota= gilt pro Kern. 100 % ist ein ganzer Kern, nicht die ganze Maschine.
- set-property ändert Dateien unter /etc/systemd/system.control/. Wer dort nicht nachschaut, sucht die Einstellung lange.
- cgroup v1 und v2: Debian 13 und Rocky 9 nutzen nur noch v2. Alte Anleitungen mit MemoryLimit= oder CPUShares= gelten nicht mehr: heute MemoryMax= und CPUWeight=.
Aufgaben
Grundaufgaben
- Lassen Sie sich mit systemd-cgls den Baum anzeigen. In welcher Slice liegt Ihre Anmeldung?
- Beobachten Sie mit systemd-cgtop, welcher Dienst gerade am meisten CPU braucht.
- Erzeugen Sie Last mit systemd-run und bremsen Sie sie mit set-property auf 20 %.
- Begrenzen Sie einen Dienst per systemctl edit auf 100 Prozesse.
Für Schnelle
- Legen Sie eine eigene Slice an und sortieren Sie zwei Last-Dienste hinein. Wie teilen sie sich die CPU?
- Setzen Sie MemoryMax=50M für einen Dienst, der mehr braucht. Was steht im Journal?
- Wo hat set-property seine Datei abgelegt?