cgroups
cgroup - Ressourcenkontrolle unter Linux
Beschreibung
Mit cgroups- lassen sich Ressourcen von Prozessen beschränken
- Ressourcensteuerung und -kontrolle umsetzen
Genutzten Arbeitsspeicher eines einzelnen Prozesses oder einer Gruppe von Prozessen beschränken
Ursprünglich als "process container" bezeichnet, können die Control-Groups (kurz: cgroups) Ressourcen (Arbeitsspeicher, CPU, I/O) limitieren, priorisieren, zählen (für Abrechnungszwecke) und isolieren
Beim Einsatz etwa von KVM-Virtualisierung sehr interessant
- Mit Cgroups lassen sich die Ressourcen eines virtuellen Gastes beschränken oder gegenüber anderen Gästen priorisieren
Gruppen
Mit einer cgroup können mehrere Prozesse zu einer Gruppe zusammenfasst werden
- Diese Prozesse und sämtliche Kindprozesse kann dann mit Parametern für bestimmte Subsysteme versehen
- Ein Subsystem ist dann etwa ein Ressource-Controller, der den verfügbaren Arbeitsspeicher verwaltet
- Beispiel
Um die Cgroups zu verwenden, muss zunächst Hierarchien anlegen, in der die Gruppen verwaltet werden
Hierzu editiert er die Datei /etc/cgconfig.conf , die in zu sehen ist
- Existiert die Datei nicht, so muss er das entsprechende Paket noch installieren
Diese Datei legt für jedes Subsystem eine eigene Hierarchie an, unterhalb derer die Cgroups angelegt werden können
- Die Hierarchie /cgroup/cpu erlaubt die Verwaltung der CPU-Shares, während /cgroup/net_cls die Verwaltung der Netz-I/O-Leistung unterstützt
- /etc/cgconfig.conf
01 mount {
02 cpuset = /cgroup/cpuset;
03 cpu = /cgroup/cpu;
04 cpuacct = /cgroup/cpuacct;
05 memory = /cgroup/memory;
06 devices = /cgroup/devices;
07 freezer = /cgroup/freezer;
08 net_cls = /cgroup/net_cls;
09 ns = /cgroup/ns;
10 blkio = /cgroup/blkio;
11 }
- Cgroups-Dateisystem
Ein Start des Cgconfig-Daemons erzeugt dann die Verzeichnisse und mountet das Cgroups-Dateisystem
Mit dem Befehl lssubsys kontrolliert der Admin die korrekte Erzeugung der Hierarchien
lssubsys
01 # lssubsys -am
02 cpuset /cgroup/cpuset
03 cpu /cgroup/cpu
04 cpuacct /cgroup/cpuacct
05 memory /cgroup/memory
06 devices /cgroup/devices
07 freezer /cgroup/freezer
08 net_cls /cgroup/net_cls
09 ns /cgroup/ns
10 blkio /cgroup/blkio
- Control Group anlegen
cgcreate -g blkio:/dd
- Block-I/O-Subsystem
Parameter für das Subsystem Block-I/O
sudo cgget -g blkio /dd
/dd:
blkio.reset_stats=
blkio.io_queued=Total 0
blkio.io_merged=Total 0
blkio.io_wait_time=Total 0
blkio.io_service_time=Total 0
blkio.io_serviced=Total 0
blkio.io_service_bytes=Total 0
Seit der Version 2.6.37 unterstützt der Kernel hier auch die Optionen blkio.throttle.*
- Damit kann die maximale I/O-Bandbreite beim Lesen und Schreiben einer Prozessgruppe einschränken
Um dies zu testen, benötigt der Admin zunächst die Major- und Minor-Nummern des Gerätes, auf dem die Bandbreite eingeschränkt werden soll
Handelt es sich um /dev/sda1 , kann er diese mit einem einfachen ls ermitteln:
sudo ls -l /dev/sda1
brw-rw----. 1 root disk 8, 1 10. Okt 08:32 /dev/sda1
Hier handelt es sich um die Major/Minor-Nummern 8 respektive 1
- Um die Bandbreite für die Control-Group nun auf 1 Mbyte/s zu beschränken, verwendet er den Befehl cgset oder einfach ein echo :
echo "8:1 1048576" > /cgroup/blkio/dd/blkio.throttle.write_bps_device
Für den Test startet er nun dd
dd if=/dev/zero of=/tmp/test & pid=$!
Zunächst arbeitet der Prozess dd in der Root-Cgroup, die nicht eingeschränkt ist
- Test
Prozess ein SIGUSR1 senden
sudo kill -USR1 $pid
578804+0 Datensätze ein
578804+0 Datensätze aus
296347648 Bytes (296 MB) kopiert, 7,00803 s,42,3 MB/s
- In die Cgroup verschieben
Prozess in die Cgroup ddverschieben
sudo echo $pid > /cgroups/blkio/dd/tasks
- Erneutes USR1-Signal
- Sendet nun erneut ein USR1-Signal an den dd -Prozess
- erkennt er, dass die durchschnittliche Bandbreite stark sinkt, da der Prozess nun nur noch mit einer Bandbreite von 1 MByte/s schreiben darf
- Statt die maximale Bandbreite zu beschränken, kann der Admin auch die Bandbreiten zwischen den Gruppen priorisieren
- blkio.weight
Hierzu dient der Parameter blkio.weight=
- Der Default-Wert beträgt 500
- Erhält eine Gruppe den Wert 1000, so kann sie doppelt so häufig auf die Block-Geräte zugreifen wie die anderen Gruppen
- cgclassify
Statt des Echo-Kommandos lassen sich Prozesse auch mit dem Kommando cgclassify einzelnen Gruppen zuweisen
- Prozess direkt in einer bestimmten Gruppe starten
Möchte der Admin einen Prozess direkt in einer bestimmten Gruppe starten, so verwendet er den Befehl cgexec :
cgexec -g blkio:dd "dd if=/dev/zero of=/tmp/test"
Automatik
Die manuelle Zuweisung von Prozessen zu verschiedenen Gruppen ist aufwendig und fehlerträchtig
- Besser ist es deshalb, wenn der Daemon cgrulesengd diese Zuweisung auch automatisch übernimmt
- Hierzu benötigt dieser Dienst die Regeldatei /etc/cgrules.conf , die ihm mitteilt, welcher Prozess von welchem Benutzer in welcher Control-Group landen soll
- Die Datei besitzt eine recht einfache Syntax:
<user>[:<process] <controllers> <destination>
Für das Beispiel mit dem dd -Kommando sieht die Regel folgendermaßen aus:
dd blkio /dd
Dies fügt die dd -Prozesse sämtlicher Benutzer der Controlgroup /dd des Blkio-Resource-Controllers hinzu
Hierarchien
Bisher betrachtet der Artikel nur einzelne isolierte Control-Groups
- Zur besseren Strukturierung lassen sich aus Gruppen aber auch
Hierarchien bilden
- So kann innerhalb einer Control-Group weitere Control-Groups anlegen, etwa mit cgreate -g blkio:/dd/user1
Diese erscheinen dann als Unterverzeichnisse und erben die Eigenschaften der übergeordneten Control-Group
Sämtliche Kind-Cgroups konkurrieren dann um die der übergeordneten Cgroup zugeteilten Ressourcen
- Darf diese nur 1 MByte/s schreiben, dürfen sämtliche Kind-Cgroups zusammen dieses Maximum nicht überschreiten
Die Ressourcen werden hierarchisch zugewiesen
- Leider funktionieren diese Hierarchien für den Blkio-Controller noch nicht
- Die anderen Controller wie CPU, Memory und so weiter unterstützen aber bereits Hierarchien
Wo können die Cgroups nun sinnvoll eingesetzt werden? Sicher gibt es spezielle Anwendungen, die im Alltag davon profitieren können
Jedoch ist es in vielen Fällen sinnvoller, dass der Linux-Kernel die Ressourcen selbstständig zuweist und hierbei keine Schranken setzt
Setzt man jedoch eine Virtualisierungslösung wie KVM ein und virtualisiert mehrere Gäste auf einem Host, gibt es durchaus Bedarf, die Ressourcennutzung der einzelnen Gäste untereinander zu beschränken, priorisieren und zu messen
- Hierfür lassen sich die Cgroups ideal einsetzen
Virtualisiert
Allerdings muss man beim Einsatz von Cgroups die Virtualisierung über die Libvirt-Bibliotheken steuern und LXC-Container oder Qemu/KVM verwenden
Der Libvirtd-Daemon erzeugt dann beim Start für jeden Gast eine eigene Cgroup mit dem Namen des Gastes
Diese befindet sich in der Hierarchie libvirtd/qemu|lxc/Gast unter jedem Controller
- Hier kann der Admin nun für jeden Gast einzeln die Ressourcen verwalten und priorisieren
Damit ein Gast doppelt so viel CPU-Zeit wie ein zweiter Gast erhalten kann, muss man im CPU-Controller die cpu.shares ändern
Das angestrebte Ziel lässt sich erreichen, indem man den Default-Wert von 1024 auf 2048 ändert
Genauso kann auch den Verbrauch des Arbeitsspeichers oder die Bandbreitennutzung im Netzwerk konfigurieren
Hierzu nutzt er den Memory-Controller oder den Net_Cls-Controller in Kombination mit dem tc -Befehl
- Allerdings unterstützen erst die aktuellsten Libvirt-Varianten den Net_Cls-Controller
Er unterscheidet sich von den anderen Controllern, da er lediglich eine Class-ID setzt und man dann mit dem Kommando tc die Bandbreite kontrolliert (siehe #Bandbreitenkontrolle)
Der Blkio-Controller lässt sich noch nicht mit Libvirt nutzen, da er noch nicht die Hierarchien unterstützt, die der Libvirtd erzeugen möchte
- Daran arbeiten die Kernel-Entwickler aber schon
Will der Admin für die verbrauchte Zeit der einzelnen virtuellen Gäste Abrechnungen erstellen, so kann er das mit dem CPUAcct-Controller erreichen
Dieser zählt für jeden Gast in /cgroup/cpuacct/libvirt/qemu/Gast/cpuacct.usage die tatsächlich verbrauchte CPU-Zeit in Nano-Sekunden
Bandbreitenkontrolle
Wird ein Prozess vom Net_cls-Controller überwacht, kann der Admin für sämtliche Prozesse der Cgroup eine Class-ID vergeben
- Diese kann dann mit dem tc Kommando genutzt werden
Hierzu setzt der Admin zunächst für die Cgroup die Class-ID:
echo 0x00100001 > /cgroup/net_cls/libvirt/qemu/Gast/net_cls.classid
Diese hexadezimale Zahl besteht aus zwei Teilen: 0xAAAABBBB
- Hierbei definieren die Ziffern AAAA die Major-Nummer der Class-ID, während die Ziffern BBBB die Minor-Nummer angeben
- Führende Nullen müssen nicht angegeben werden
- Der obige Ausdruck hätte also auch 0x100001 lauten können
Um nun die Class-ID zu nutzen, muss der Admin eine Classbased-Queueing-Discipline (QDisc) auf der ausgehenden Netzwerkkarte (etwas eth0 ) installieren
Die QDisc entscheidet, wann ein Paket zu versenden ist
- Eine klassenbasierte QDisc erlaubt die Einsortierung der Pakete in unterschiedliche Klassen sowie die Priorisierung und Beschränkung dieser Klassen
Eine klassische QDisc für die Beschränkung des Netzwerkverkehrs ist der Hierarchical Token Bucket Filter (HTB)
- Der Admin muss zunächst diesen auf der Netzwerkkarte installieren
Hierzu löscht er eine möglicherweise vorhandene QDisc und lädt dann den HTB:
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc add dev etho root handle 10: htbU
Nun muss der Admin die Klassen erzeugen
tc class add dev eth0 parent 10: classid 10:1 htb rate 10mbit
tc class add dev eth0 parent 10: classid 10:2 htb rate 20mbit ceil 100mbit
Diese zwei Zeilen erzeugen zwei verschiedene Klassen
- Die erste Klasse verfügt über eine maximale Bandbreite von 10 Megabit/s
- Die zwei Klasse verfügt über 20 Megabit/s, darf jedoch bis zu einer maximalen Bandbreite von 100 Mbit/s beanspruchen, wenn keine andere Klasse Ansprüche erhebt
- Die Option default 2 bei der Erzeugung des HTB weist unklassifizierten Verkehr der zweiten Klasse zu
Um die Class-ID der Cgroup Net_Cls nun auszuwerten, muss der Admin noch einen Filter definieren:
tc filter add dev eth0 parent 10: \
protocol ip prio 10 \
handle 1: cgroup
Nun wird die Net_Cls-Class-ID automatisch von dem Kernel für die Einsortierung der Pakete in den HTB-Klassen genutzt
- Der Libvirt-Gast erhält nun eine maximale Sendeleistung von 10 Mbit/s
Jeder Thread eines Prozesses kann in einer eigenen Cgroup kontrolliert werden
Daran muss denken, wenn er, wie zu Beginn gezeigt, die Prozesse nach ihrem Start mit dem echo-Kommando einer Cgroup zuweisen möchte
Auch sämtliche gestarteten Threads (/proc/pid/task/ ) muss er entsprechenden Cgroups zuweisen
Einfacher ist da das Kommando cgexec
- Dieser Befehl startet den Prozess bereits in der Cgroup
- Alle Kindprozesse und -threads erben dann diese Gruppe
Aufruf
Optionen
Unix | GNU | Parameter | Beschreibung |
---|---|---|---|
Parameter
Umgebungsvariablen
Exit-Status
Wert | Beschreibung |
---|---|
0 | Erfolg |
>0 | Fehler |
Anwendung
cgroup tree
sudo systemd-cgls
└ system
├ 1 /usr/lib/systemd/systemd --system --deserialize 18
├ ntpd.service
│ └ 8471 /usr/sbin/ntpd -u ntp:ntp -g
├ upower.service
│ └ 798 /usr/libexec/upowerd
├ wpa_supplicant.service
│ └ 751 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
├ nfs-idmap.service
│ └ 731 /usr/sbin/rpc.idmapd
├ nfs-rquotad.service
│ └ 753 /usr/sbin/rpc.rquotad
├ nfs-mountd.service
│ └ 732 /usr/sbin/rpc.mountd
├ nfs-lock.service
│ └ 704 /sbin/rpc.statd
├ rpcbind.service
│ └ 680 /sbin/rpcbind -w
├ postfix.service
│ ├ 859 /usr/libexec/postfix/master
│ ├ 877 qmgr -l -t fifo -u
│ └ 32271 pickup -l -t fifo -u
├ colord-sane.service
│ └ 647 /usr/libexec/colord-sane
├ udisks2.service
│ └ 615 /usr/lib/udisks2/udisksd --no-debug
├ colord.service
│ └ 607 /usr/libexec/colord
├ prefdm.service
│ ├ 567 /usr/sbin/gdm-binary -nodaemon
│ ├ 602 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
│ ├ 612 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-O00GPA/database -seat seat0 -nolisten tcp
│ └ 905 gdm-session-worker [pam/gdm-password]
├ systemd-ask-password-wall.service
│ └ 645 /usr/bin/systemd-tty-ask-password-agent --wall
├ atd.service
│ └ 544 /usr/sbin/atd -f
├ ksmtuned.service
│ ├ 548 /bin/bash /usr/sbin/ksmtuned
│ └ 1092 sleep 60
├ dbus.service
│ ├ 586 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
│ ├ 601 /usr/libexec/polkit-1/polkitd --no-debug
│ └ 657 /usr/sbin/modem-manager
├ cups.service
│ └ 508 /usr/sbin/cupsd -f
├ avahi-daemon.service
│ ├ 506 avahi-daemon: running [epsilon.local]
│ └ 516 avahi-daemon: chroot helper
├ system-setup-keyboard.service
│ └ 504 /usr/bin/system-setup-keyboard
├ accounts-daemon.service
│ └ 502 /usr/libexec/accounts-daemon
├ systemd-logind.service
│ └ 498 /usr/lib/systemd/systemd-logind
├ crond.service
│ └ 486 /usr/sbin/crond -n
├ NetworkManager.service
│ ├ 484 /usr/sbin/NetworkManager --no-daemon
│ └ 8437 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-903b6f6aa7a1-46c8-82a9-7f637dfbb3e4-wlan0.lease -cf /var/run/nm-d...
├ libvirtd.service
│ ├ 480 /usr/sbin/libvirtd
│ └ 571 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listenaddress 192.168.122.1 --dhcp-range 192.168.122.2,1...
├ bluetooth.service
│ └ 479 /usr/sbin/bluetoothd -n
├ systemd-udev.service
│ └ 287 /usr/lib/systemd/systemd-udevd
└ systemd-journald.service
└ 280 /usr/lib/systemd/systemd-journald
ps with cgroups
alias psc='ps xawf -eo pid,user,cgroup,args
psc
PID USER CGROUP COMMAND
...
1 root name=systemd:/systemd-1 /bin/systemd systemd.log_target=kmsg systemd.log_level=debug selinux=0
415 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
928 root name=systemd:/systemd-1/atd.service /usr/sbin/atd -f
930 root name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n
932 root name=systemd:/systemd-1/crond.service /usr/sbin/crond -n
935 root name=systemd:/systemd-1/auditd.service /sbin/auditd -n
943 root name=systemd:/systemd-1/auditd.service \_ /sbin/audispd
964 root name=systemd:/systemd-1/auditd.service \_ /usr/sbin/sedispatch
937 root name=systemd:/systemd-1/acpid.service /usr/sbin/acpid -f
941 rpc name=systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f
944 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c 4
947 root name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger
950 root name=systemd:/systemd-1/cups.service /usr/sbin/cupsd -f
955 dbus name=systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
969 root name=systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6
970 root name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5
971 root name=systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1
973 root name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4
974 root name=systemd:/user/lennart/2 login -- lennart
1824 lennart name=systemd:/user/lennart/2 \_ -bash
975 root name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3
988 root name=systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd
994 rtkit name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
...
Problembehebung
Konfiguration
Dateien
Datei | Beschreibung |
---|---|
Anhang
Siehe auch
Dokumentation
- Man-Page
- Info-Pages
Links
Projekt
Weblinks