Im ersten Teil habe ich die Funktion und Verwendung von cgroups für die Systemadministration und Leistungsoptimierung besprochen. Im zweiten Teil habe ich die Komplexität der cgroups- und CPUShares-Werte angemerkt. Hier im dritten Teil konzentriere ich mich auf manuelle Verwaltungsaufgaben für Cgroups.
Vergessen Sie nicht, in Teil vier weiterzulesen, wie cgroups mit systemd funktionieren.
Cgroups auf die harte Tour machen
Werfen wir einen Blick darauf, wie Cgroups ohne die Tools um sie herum erstellt werden. Cgroups sind im Kern einfach eine Verzeichnisstruktur mit cgroups in sie eingebaut. Sie können sich überall im Dateisystem befinden, aber Sie finden die vom System erstellten Kontrollgruppen in /sys/fs/cgroup standardmäßig. Wie erstellt man Cgroups? Beginnen Sie mit der Erstellung des folgenden Verzeichnisses der obersten Ebene:
# mkdir -p /my_cgroups Nachdem dies erstellt wurde, entscheiden Sie, welche Controller Sie verwenden möchten. Denken Sie daran, dass die Struktur für cgroups Version 1 etwa so aussieht:
/my_cgroups
├── <controller type>
│ ├── <group 1>
│ ├── <group 2>
│ ├── <group 3> [ Den Lesern gefiel auch:Eine Einführung in crun, eine schnelle Container-Laufzeitumgebung mit geringem Speicherbedarf ]
Alle Gruppen, die Sie erstellen möchten, werden separat unter jedem Controller-Typ verschachtelt. Daher Gruppe1 unter dem Controller memory ist völlig unabhängig von Gruppe1 im blkio . Lassen Sie uns vor diesem Hintergrund ein einfaches CPUShares-Beispiel erstellen.
Der Einfachheit halber erzeuge ich eine Last auf dem System, indem ich Folgendes ausführe:
# cat /dev/urandom Dadurch wird das System für eine einfache Messung künstlich belastet. Dies ist kein reales Lastbeispiel, aber es hebt die Hauptpunkte von CPUShares hervor. Ich habe auch eine virtuelle Maschine eingerichtet, auf der CentOS 8 mit einer einzigen vCPU ausgeführt wird, um die Mathematik wirklich einfach zu machen. In Anbetracht dessen besteht der erste Schritt darin, einige Verzeichnisse für unsere Cgroup-Controller zu erstellen:
# mkdir -p /my_cgroups/{memory,cpusets,cpu} Hängen Sie als Nächstes die cgroups in diesen Ordnern ein:
# mount -t cgroup -o memory none /my_cgroups/memory
# mount -t cgroup -o cpu,cpuacct none /my_cgroups/cpu
# mount -t cgroup -o cpuset none /my_cgroups/cpusets
Um Ihre eigenen Cgroups zu erstellen, erstellen Sie einfach ein neues Verzeichnis unter dem Controller, den Sie verwenden möchten. In diesem Fall habe ich es mit der Datei cpu.shares zu tun , die sich in cpu befindet Verzeichnis. Lassen Sie uns also ein paar cgroups unter cpu erstellen Controller:
# mkdir -p /my_cgroups/cpu/{user1,user2,user3} Beachten Sie, dass die Verzeichnisse automatisch vom Controller ausgefüllt werden:
# ls -l /my_cgroup/cpu/user1/
-rw-r--r--. 1 root root 0 Sep 5 10:26 cgroup.clone_children
-rw-r--r--. 1 root root 0 Sep 5 10:26 cgroup.procs
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.stat
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_all
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu_sys
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu_user
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_sys
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_user
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.cfs_period_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.cfs_quota_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.rt_period_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.rt_runtime_us
-rw-r--r--. 1 root root 0 Sep 5 10:20 cpu.shares
-r--r--r--. 1 root root 0 Sep 5 10:26 cpu.stat
-rw-r--r--. 1 root root 0 Sep 5 10:26 notify_on_release
-rw-r--r--. 1 root root 0 Sep 5 10:23 tasks Jetzt, da ich einige cgroups eingerichtet habe, ist es an der Zeit, etwas Last zu generieren. Dazu öffne ich einfach drei SSH-Sitzungen und führe im Vordergrund folgenden Befehl aus:
# cat /dev/urandom
Sie können die Ergebnisse in top sehen :
WICHTIGER HINWEIS :Denken Sie daran, dass die CPUShares auf der Cgroup der obersten Ebene basieren, die standardmäßig uneingeschränkt ist. Das bedeutet, sollte ein Prozess weiter oben im Baum CPUShares anfordern, wird das System diesem Prozess Priorität einräumen. Das kann Menschen verwirren. Es ist wichtig, eine visuelle Darstellung des Cgroup-Layouts auf einem System zu haben, um Verwirrung zu vermeiden.
Im obigen Screenshot können Sie sehen, dass die gesamte cat Prozesse erhalten mehr oder weniger die gleiche Menge an CPU-Zeit. Dies liegt daran, dass cgroups standardmäßig den Wert 1024 in cpu.shares erhalten . Diese Anteile werden, wie bereits erwähnt, durch die Beziehung des Elternteils zu anderen Cgroups eingeschränkt. In unserem Beispiel habe ich bei keinem Elternteil das Gewicht angepasst. Wenn daher alle übergeordneten Kontrollgruppen gleichzeitig Ressourcen anfordern, gilt die Standardgewichtung von 1024 CPUShares.
Zurück zu unserem Beispiel:Ich habe eine cgroup mit einigen Standardwerten erstellt. Das bedeutet, dass jede Gruppe das Standardgewicht von 1024 hat. Um dies zu ändern, ändern Sie einfach die Werte in cpu.shares Datei:
# echo 2048 > user1/cpu.shares
# echo 768 > user2/cpu.shares
# echo 512 > user3/cpu.shares
Ausgezeichnet, ich habe jetzt eine kompliziertere Gewichtungsberechnung, aber ich habe der Kontrollgruppe eigentlich keine Prozesse hinzugefügt. Daher ist die cgroup inaktiv. Um einen Prozess zu einer Kontrollgruppe hinzuzufügen, fügen Sie einfach die gewünschte PID zu den tasks hinzu Datei:
# echo 2023 > user1/tasks
Hier ist das Ergebnis des Hinzufügens eines Prozesses zu einer Kontrollgruppe, wie in top zu sehen :
Wie Sie im obigen Screenshot sehen, erhält der Prozess in der neuen cgroup ungefähr die Hälfte der CPU-Zeit. Das liegt an der Gleichung von früher:
Lassen Sie uns fortfahren und die anderen beiden Prozesse zu ihren jeweiligen Cgroups hinzufügen und die Ergebnisse beobachten:
# echo 2024 > user2/tasks
# echo 2025 > user3/tasks 
Wir sehen nun, dass die Gewichtung mit der cgroup user1 gegriffen hat etwa 61 % der CPU-Zeit einnehmen:
Die verbleibende Zeit wird zwischen Benutzer2 aufgeteilt und user3 .
Es gibt natürlich einige Probleme mit unserem Testaufbau.
- Diese werden alle von Hand erstellt. Was passiert, wenn der Prozess, den Sie in eine Kontrollgruppe einfügen, seine PID ändert?
- Die erstellten benutzerdefinierten Dateien und Ordner überleben einen Neustart nicht.
- Das ist viel Handarbeit. Wo ist das Werkzeug?
Keine Angst, meine Freunde, systemd hat alles im Griff.
[ Kostenloser Online-Kurs:Technischer Überblick zu Red Hat Enterprise Linux. ]
Schluß
Jetzt, da wir die manuelle Verwaltung von cgroups besser verstehen, können wir den Wert der Zusammenarbeit von cgroups und systemd besser einschätzen. Ich untersuche diese Idee in Teil vier dieser Serie. Teil vier ist übrigens der Schluss.