In Teil eins dieser Serie habe ich die grundlegenden Konzepte von Cgroups besprochen und wie Cgroups dabei helfen, Leistung und Sicherheit auf Linux-Servern zu verwalten. Hier im zweiten Teil bespreche ich den CPUShares-Wert und wie er von cgroups verwendet wird. Vergessen Sie nicht, dass ich in Teil drei auf die Cgroup-Verwaltung schaue und in Teil vier mit cgroups schließe, wie sie mit systemd interagieren.
Ein wenig über Linux-Aufzüge
Ich werde mich in diesem Abschnitt sehr eng auf Red Hat Enterprise Linux (RHEL) konzentrieren. Bei meinem kurzen Blick auf die wenigen Ubuntu-Boxen in meinem Labor bemerkte ich jedoch Ähnlichkeiten mit dem I/O-Scheduler. Daher könnten einige meiner Punkte auch für andere Distributionen gelten. Die meisten Produkte der Red Hat-Produktfamilie (Fedora, CentOS und RHEL) verwenden entweder deadline oder cfq als Standardplaner.
- Completely Fair Queuing (CFQ):Betont E/A aus Echtzeitprozessen und verwendet historische Daten, um zu entscheiden, ob eine Anwendung in naher Zukunft mehr E/A-Anforderungen ausgeben wird.
- Deadline:Versucht, eine garantierte Latenzzeit für Anfragen bereitzustellen und ist besonders geeignet, wenn Lesevorgänge häufiger als Schreibvorgänge auftreten. Es gibt eine Warteschlange für Lesevorgänge und eine für Schreibvorgänge. Operationen werden basierend auf der in der Warteschlange verbrachten Zeit abgeschlossen, und der Kernel wird immer versuchen, Anforderungen zu verarbeiten, bevor ihre maximale Zeit verstrichen ist. Lesevorgänge haben standardmäßig Vorrang vor Schreibstapeln.
Vor diesem Hintergrund neigt RHEL dazu, cfq zu verwenden für SATA-basierte Laufwerke und deadline für alle anderen Fälle standardmäßig. Dies spielt eine wichtige Rolle bei der Abstimmung Ihres Systems. Diese Planer können natürlich geändert werden, und Sie sollten Ihre Arbeitsbelastung untersuchen und den Planer auswählen, der am besten zu Ihrer(n) Aufgabe(n) passt. Es ist auch erwähnenswert, dass ein Planer pro Blockgerät ausgewählt werden kann . Das bedeutet, dass Sie mehrere Scheduler auf einem einzigen System haben können, je nachdem, wie Ihre Festplatten konfiguriert sind.
[Das könnte Ihnen auch gefallen:Einrichten von containerisierten SSH-Servern für die Sitzungsaufzeichnung mit tlog ]
CPU-Freigaben
Die CPUShares value stellt Aufgaben in einer Kontrollgruppe eine relative Menge an CPU-Zeit zur Verfügung. Sobald das System den cpu cgroup Controller gemountet hat, können Sie die Datei cpu.shares verwenden um die Anzahl der der Kontrollgruppe zugeteilten Aktien festzulegen. Die CPU-Zeit wird bestimmt, indem die CPUShares der Kontrollgruppe durch die Gesamtzahl der definierten CPUShares auf dem System dividiert werden. Diese Berechnung der CPU-Zeit wird ziemlich kompliziert, also schauen wir uns einige Diagramme an, um die Dinge zu verdeutlichen.
Das obige Diagramm zeigt einige der häufigsten Elemente auf einem RHEL 7 OpenShift Container Platform-Steuerungsebenenserver. Jeder Prozess auf diesem System beginnt mit dem / cgroup.
In RHEL beginnt dies mit dem Stamm / cgroup mit 1024 Freigaben und 100 % der CPU-Ressourcen. Der Rest der Ressourcen wird gleichmäßig auf die Gruppen /system.slice aufgeteilt , /user.slice und /kubepod.slice , die standardmäßig jeweils die gleiche Gewichtung von 1024 haben, wie unten zu sehen ist:
In diesem Szenario ist die Logik ziemlich einfach:Jeder Slice kann nur 33 % der CPUShares verwenden, wenn alle Cgroups gleichzeitig Shares anfordern. Die Mathematik ist ziemlich einfach:
Und wenn Sie die Zahlen einfügen:
Was ist jedoch, wenn Sie sich entscheiden, Gruppen zu verschachteln oder die Gewichtung von Gruppen auf derselben Ebene zu ändern? Unten sehen Sie ein Beispiel für die verschachtelten Gruppen:
In diesem Beispiel sehen Sie, dass ich eine Kontrollgruppe für verschiedene Benutzer erstellt habe. Hier wird die Mathematik interessant. Zuerst würden Sie denken, dass die folgende Gleichung gut funktionieren würde:
Dies sind jedoch nur 23 % der 33 %, die user.slice zugeteilt werden . Das bedeutet Benutzer1 hat ungefähr 7,6 % der gesamten CPU-Zeit, basierend auf diesen Gewichtungen im Falle von Ressourcenkonflikten.
CPUShares wurde einfach in Eile kompliziert. Zum Glück sind die meisten anderen Controller geradliniger als dieser.
[ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]
Abschluss
Die CPUShares-Werte können Cgroups sehr komplex erscheinen lassen. Das ist einer der Gründe, warum ich CPUShares hier behandeln wollte. Die richtige Verwendung von CPUShares hilft Ihnen jedoch, Ihr System effizienter und genauer zu verwalten.
Im nächsten Artikel dieser Serie gehe ich auf die Cgroup-Verwaltung ein. Ich hoffe, dass Sie diese Serie weiterhin verfolgen werden. In Teil vier werde ich unsere Diskussion mit systemd und cgroups abschließen.