PSI – Pressure Stall Information

Solange nichts anderes angegeben Screenshots & Videos: CL | Lizenz: CC-by-sa 4.0

1. Vorwort

Die drei Grundbausteine ​​unseres Computers, Prozessor (CPU), Ein-/Ausgabe (E/A) und Arbeitsspeicher (RAM) können aufgrund von Last in Konflikte geraten, was nicht ungewöhnlich ist. Sind alle oder ein Teil der Grundbausteine aufgebraucht, streiten sich die Prozesse darum und es kommt zu Ressourcenkonflikten. Daher empfiehlt es sich, den Ressourcenverbrauch von Anwendungen genau zu beobachten, um die Hardware-Anforderungen korrekt zu bemessen und vorhandene Hardware optimal auszulassen.
Dies gilt auch für interaktive Arbeitslast (z. B. Smartphones), bei denen Lastinformationen verwendet werden können, um Hintergrundprozesse zu beenden und dem Vordergrundprozess so viele Ressourcen wie möglich zur Verfügung zu stellen, damit unser Nutzungserlebnis (UX) bestmöglich ist.

2. Einschränkungen von Linux Lastdurchschnitt – Load Average

Aber waren wir nicht immer in der Lage, die Systemlast mit Lastmittelwerten zu messen? Das ist richtig, aber Lastdurchschnitte (loadavg) haben einige Mängel. Sehen wir uns zunächst einmal an, wie Lastdurchschnitte aussehen, indem wir den Befehl uptime ausführen:

Die drei Lastdurchschnitte (loadavg im Detail) gelten für die letzten 1, 5 und 15 Minuten zum Zeitpunkt der Ausführung des Befehls. Unter Linux tragen sowohl Prozesse, die auf die CPU warten, als auch solche, die auf E/A warten, zum Lastdurchschnitt bei. Das bedeutet, dass wir wissen, wann eine der beiden Arten von Mangel auftritt. Warum war also eine Verbesserung darüber hinaus erforderlich? Mit anderen Worten, warum ist eine Fähigkeit wie PSI erforderlich?

• Lastmittelwerte (loadavg) müssen relativ zur CPU-Zahl interpretiert werden. Beispielsweise bedeutet ein Lastdurchschnitt von 4,0 auf einem System mit 4 CPU-Kernen, dass es überhaupt keine Mangel gibt. Dies liegt daran, dass die gemeldeten Lastdurchschnitte die Anzahl der wartenden Prozesse darstellen. Sie können die tatsächlich fehlende Zeit, für die Prozesse, nicht abrufen.
• CPU und E/A werden in einer Zahl zusammengefasst. Wenn Du sie getrennt verfolgen willst, hast du Pech. Weil Sie Arbeitslasten haben, die sowohl auf CPU- als auch auf E/A-Mangel reagieren.
• Die Mindestauflösung für die echte Aktualisierungen der Last beträgt eine Minute. Wenn Du z.B. die Ausgabe der Betriebszeit mit dem Befehl watch kontinuierlich überwachst, während Du eine einfache Schleife ausführst, wird die Schleife sofort 100% der CPU beanspruchen und andere Prozesse auf einem Einkernsystem blockieren. Der 1-Minuten-Lastmittelwert nähert sich jedoch erst eine volle Minute später der 1.0-Marke. Wenn Du den Lastdurchschnitt beobachtest hast, um eine schnelle Entscheidung über deine CPU-sensiblen Arbeitslast zu treffen, hast Du Pech gehabt.

3. Linux Pressure Stall Information – PSI

Eine Antwort auf die Grenzen der durchschnittlichen Belastung ist die PSI. Obwohl es im Linux-Kernel-Version 4.20.x hinzugefügt wurde, verfügt es mit Kernel 5.2.x erst über die nötigen zusätzliche Funktion, Programme zu benachrichtigen, die wissen müssen, ob sich innerhalb eines bestimmten Zeitfensters eine bestimmte Last aufbaut. Damit spielt PSI in einer ganz anderen Liga als loadavg, bei der es sich lediglich um statische Informationen handelt.

3.1 Voraussetzung

Für diesen Artikel habe ich Kernel 5.7.9 von Fedora verwendet. Du musst auch sicherstellen das PSI im Kernel aktiviert ist.

ls -l /proc/pressure

3.2 /proc/pressure/cpu

Werfen wir einen Blick auf den Inhalt der Datei :

Du siehst vier Gesamtfelder: avg10, avg60 und avg300 und total. Die avg*-Felder stellen den Prozentualen Anteil der Zeit in den letzten 10, 60 bzw. 300 Sekunden dar, in der Prozesse CPU Zeit benötigt haben. Wenn beispielsweise ein Prozess in den letzten 300 Sekunden 100% der CPU Zeit eines Einkernsystems beanspruchte, wären alle diese Zahlen gleich Null. Das bedeutet, dass es keinen Mangel gab, da es einen Prozess für die eine verfügbare CPU gab, aber keine Konkurrenz durch einen anderen Prozess für die CPU. Nun, obwohl diese Werte unabhängig von der Anzahl der verfügbaren CPUs interpretiert werden können, unterscheiden sie sich nicht sehr von unserem alten Freund, dem Lastdurchschnitt (loadavg). Doch während die minimale verfügbare Auflösung für den Lastdurchschnitt 1 Minute betrug, haben wir hier 10 Sekunden. Da Lastinformationen über die CPU dir 6x schneller als der Lastdurchschnitt (loadavg) zur Verfügung steht, ist PSI bereits nützlich, aber wir kratzen mit dieser PSI Betrachtung nur an der Oberfläche.

Das total Feld ist viel interessanter. Es stellt die Gesamtzeit in Mikrosekunden dar, die für Prozesse an der CPU verbraucht wurden. Wenn Du diese Datei weiterhin alle 100 Millisekunden lesen und den Wert der zuvor gelesenen Gesamtzahl abziehst. Erhältst Du die Zeit in Mikrosekunden, für die Prozesse zwischen dem vorherigen Lesen und jetzt von der CPU unterversorgt war. Es handelt sich hier also um etwas sehr Hochauflösendes. Dies ist mit nichts vergleichbar, was früher unter Linux verfügbar war.

Das total Feld aktualisiert praktisch in Echtzeit. Während die Aktualisierung der Felder avg10, avg60 und avg300 einige Zeit in Anspruch nimmt, brauchst Du auf das total Feld nicht zu warten. Durch diese Art der hohen Auflösung erhältst Du nahezu sofortiges Feedback, um zu prüfen, ob die Arbeitslasten innerhalb einer akzeptablen Lastgrenze liegen. Ist dies nicht der Fall, kann entschieden werden, ob z.B. Aufgaben mit niedriger Priorität abgebrochen werden oder einige Arbeitslasten auf andere Systeme zu verschieben.

3.3 /proc/pressure/io & /proc/pressure/memory

Kommen wir nun zu den beiden anderen Dateien:

Im Gegensatz zur Datei /proc/pressure/cpu haben diese beiden Dateien zwei Zeilen statt einer. Die Zeile mit dem Präfix „some“ stellt die Last für mindestens einen Prozess dar, der hätte laufen können, während die Zeile mit dem Präfix „full“ die Last für alle Prozesse darstellt. Wenn Du eine große Anzahl von Dateien in voller Größe siehst, bedeutet dies, dass kein lauffähiger/nicht im Leerlauf befindlicher Prozess ausgeführt werden konnte und die CPU mit Aufräumarbeiten im Zusammenhang mit dem Auslagern beschäftigt war. Selbst kleine Zahlen hier sollten Dich beunruhigen, da sie eindeutig auf Arbeitslasten hinweisen, denen der Arbeitsspeicher fehlt. Während also die Zahlen in einigen Fällen darauf hinweisen, dass das System zwar mit Ressourcen überlastet ist und einige lauffähige Prozesse wartend sind, bedeutet dies jedoch, dass andere Prozesse weiterlaufen und echte Arbeit geleistet wird. Wenn Du jedoch die Zahlen in voller Höhe siehst, bedeutet das, dass keine echten Benutzerprozesse laufen. Es ist also eine clevere Art und Weise, eine Menge Bedeutung in nur zwei Zeilen Text zu verpacken.

3.3.1 Kennzahl some/full im Detail

Die some Statistik gibt den Prozentsatz der Zeit an, in der einige (eine oder mehrere) Aufgaben aufgrund von Ressourcenmangel verzögert wurden – beispielsweise aufgrund von Speichermangel. In der folgenden Abbildung wurde Task A ohne Verzögerung ausgeführt, während Task B 30 Sekunden auf den Speicher warten musste, was zu einem some Wert von 50% führte.

some Dies weist auf eine zusätzliche Latenz aufgrund fehlender Ressourcen hin: Während der Gesamtaufwand der CPU möglicherweise gleich geblieben ist, dauerten einige Aufgaben länger.

Die full Metrik gibt den Prozentsatz der Zeit an, in der alle Aufgaben durch Ressourcenmangel verzögert wurden, d.h. die Menge an völlig unproduktiver Zeit. Im folgenden Beispiel wartete Task B 30 Sekunden auf den Speicher. Während 10 dieser Sekunden wartete auch Task A. Dies ergibt einen full Wert von 16,66% und einen some Wert von 50%.

Eine hoher full Wert weist auf einen Verlust des Gesamtdurchsatzes hin – der Gesamtaufwand für die geleistete Arbeit nimmt aufgrund fehlender Ressourcen ab.

Beachte, dass die Statistiken die kumulierten Zeiten widerspiegeln, auf die Aufgaben über den Zeitraum gewartet haben, unabhängig davon, ob die Wartezeiten zusammenhängend waren (wie in den obigen Beispielen), oder eine Reihe diskreter Wartezeiten über denselben Zeitraum:

Bilder: facebookmicrosites | Lizenz: Unbekannt

Die Messwerte für den Zeitdruck sind einfach zu lesen und können auf kürzliche Verzögerungen oder vor und nach bestimmten Aufgabenoperationen abgetastet werden, um deren Ressourcen bezogene Latenzen zu bestimmen.

Es ist auch erwähnenswert, dass PSI in der Lage ist, zwischen Paging und Thrashing zu unterscheiden, was sehr schön ist. Für Lastinformationen wird nur Thrashing berücksichtigt.

4. System Monitoring mit Watch

watch -n 2 -d head /proc/pressure/*

4.1 Cgroups2

watch -n 2 -d head /sys/fs/cgroup/*.pressure

An dieser stelle möchte ich auf diesen Artikel verweisen, weil Cgroups ein eigenes Großes Thema ist.

4.2 Atop

Kann PSI seit atop: >v2.4 (ca. 12. January 2019)

man atop

atop 2

4.3 Stresstest

4.3.1 Video

5. Quellen:

https://linuxwiki.de/proc/loadavg
https://linuxwiki.de/LoadAverage
https://lwn.net/Articles/759781/
https://www.kernel.org/doc/html/latest/accounting/psi.html
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/accounting/psi.rst
https://facebookmicrosites.github.io/psi/
https://unixism.net/2019/08/linux-pressure-stall-information-psi-by-example/
https://www.linux-magazin.de/ausgaben/2020/08/psi/
https://www.atoptool.nl/downloadatop.php
https://amanusk.github.io/s-tui/