Wir untersuchen weiterhin die Kontrollgruppen (Cgroups) in Red Hat Enterprise Linux 7. Wir kümmern uns um den Speicher.
Sie erinnern sich, dass die Zuweisung der Prozessorzeit zwei Anpassungen vorgenommen hat: CPUShares zum Festlegen relativer Freigaben und CPUQuota, um den Benutzer, den Dienst oder die virtuelle Maschine (VM) in absoluten Werten (Prozent) der Prozessorzeit zu begrenzen. Darüber hinaus können diese beiden Einstellungen gleichzeitig verwendet werden. Wenn ein Benutzer beispielsweise ein CPU-Kontingent von 50% hat, wird auch sein CPU-Ball berücksichtigt, bis er sein Kontingent bei 50% der Prozessorzeit vollständig ausgewählt hat.
Was RAM betrifft, bietet systemd nur eine Möglichkeit zum Anpassen, nämlich ...
Die Speichermenge, die einem Benutzer oder Dienst zugewiesen werden kann. Angenommen, wir möchten den Benutzer mrichter auf 200 MB RAM beschränken. Wenn Sie sich erinnern, ist die UID 1000, daher geben wir den folgenden Befehl ein:
systemctl set-property user-1000.slice MemoryLimit = 200M
Jetzt will mrichter seine Grenzen überprüfen und startet den Stresstest Utility Stress, der anfängt, Speicher intensiv zu verbrauchen. Und Stress erzeugt sehr schnell einen Fehler:
Laut Systemprotokoll wurde der Stress einfach durch OOM (Out Of Memory) Killer unterbrochen.
Hierbei ist zu beachten: Standardmäßig gilt das RAM-Limit nur für den residenten Speicher. Das heißt, wenn der Prozess zur Auslagerungsdatei ("Auslagerung") wechseln kann, wird das festgelegte Limit umgangen. In unserem Beispiel ist Stress abgestürzt, weil er die Grenze für den residenten Speicher überschritten hat.
Und wenn wir nicht wollen, dass das Programm zu einem Swap verschmilzt?
Dies ist im Allgemeinen leicht zu verbieten. Gut oder relativ einfach ... Im Allgemeinen muss man irgendwo klettern.
Es gibt cgroup-Einstellungen, die weder über den Befehl systemctl noch über Unit-Dateien erreicht werden können. Diese Einstellungen können jedoch im laufenden Betrieb über die Dateien im Ordner / sys / fs / cgroup / geändert werden. So sieht zum Beispiel Crich von User Richter im Speicher aus:
Die Datei, die dafür verantwortlich ist, wie viel Speicher in den Swap gelangen kann, heißt ganz offensichtlich memory.swappiness. Mal sehen, was drin ist:
Wenn Sie zufällig mit den Kerneleinstellungen und dem Swap-Subsystem spielen, wird hier sofort der Standardwert für den Swapiness-Parameter angezeigt. Wenn Sie ihn auf Null ändern, verbietet ihm der RAM-Controller für den Benutzer mrichter im Allgemeinen die Verwendung eines Swaps.
Übrigens können Sie hier die Speicherstatistik für den Benutzer mrichter einsehen:
Der Wert des Parameters hierarchical_memory_limit ist derselbe MemoryLimit, den wir mit dem Befehl systemctl angegeben haben. Der Parameter hierarchical_memsw_limit stellt das Gesamtlimit dar (residenter Speicher und Speicher in der Datei der Datei). Wir haben verhindert, dass Benutzer mrichter die Auslagerungsdatei verwendet, daher ist der Wert dieses Parameters so seltsam.
Nun zu den Problemen des gerade beschriebenen Ansatzes:
- Sie können Änderungen an diesen Dateien nur vornehmen, wenn sich der Benutzer mrichter am System angemeldet hat. Bis er sich anmeldet, ist seine cgroup inaktiv.
- Diese Einstellungen werden nach einem Neustart nicht gespeichert. Außerdem gehen sie verloren, wenn der Richter übergeht.
Das Skript pam_exec hilft bei der Bewältigung dieser Probleme (
Einzelheiten finden Sie unter
access.redhat.com/solutions/46199 ).
Hier ist das Skript, das wir im Ordner / usr / local / bin erstellen:
Fügen Sie dann seinen Anruf in die letzte Zeile von /etc/pam.d/sshd ein. Infolgedessen wird dieses Skript jedes Mal ausgeführt, wenn sich ein Benutzer über ssh anmeldet. Aus diesem Grund überprüfen wir im Skript, ob dies der Benutzer mrichter ist, bevor wir die Einstellungen ändern.
Also haben wir den Benutzer mrichter von der Auslagerungsdatei abgeschnitten.
Natürlich können Sie noch weiter gehen und die Konfigurationsdateien der aktiven cgroup im laufenden Betrieb ändern, aber wir werden dieses riskante Geschäft vorerst verschieben. Die allgemeine Methode zum Ändern von Benutzereinstellungen ist jedoch etwas, das Sie verstanden haben.
Und mit Dienstleistungen ist es noch einfacher. In der Service Unit-Datei können Sie mit der Anweisung ExecStartPost = ein Skript ausführen, das die Einstellungen ändert. So ändern Sie beispielsweise die Datei der foo-Serviceeinheit, um das Austauschen zu deaktivieren:
Foo ausführen - und kein Tausch:
Nun, für heute ist dieser Schamanismus vielleicht genug für uns.
Bevor wir jedoch fertig sind, wollen wir uns mit der cgroup-Dokumentation befassen, in der Sie Informationen zu all diesen versteckten Reglereinstellungen finden. Sie können das Kernel-Doc-Paket auf Ihrem Computer installieren, indem Sie es aus dem Repository rhel-7-server-rpms herunterladen.
Öffnen Sie nach der Installation den Ordner / usr / share / docs, der Ihrem Kernel entspricht, und wechseln Sie zum Ordner cgroups, der die neuesten Informationen zu allen Regulierungsbehörden enthält.
Nächstes Mal werden wir über I / O sprechen. Übrigens haben wir fast herausgefunden, wie cgroups zur Entstehung von Containern geführt haben (tatsächlich ist cgroups eine Schlüsselkomponente von Containern in Red Hat Enterprise Linux und Red Hat OpenShift Container Platform).