Mit Bordmitteln kommen Sie lästigen Ressourcenfressern schnell auf die Schliche und helfen Ihrem System wieder auf die Sprünge.

Top gehört wohl zu den ersten Monitoring-Tools, mit denen man unter Linux in Berührung kommt. Ich kenne aber Nutzer, die es als altbacken, kryptisch und eher arm an Features einstufen und deswegen Htop bevorzugen. Unbestritten, die Entwickler liefern Top wenig spektakulär aus (Abbildung 1). Dabei liefert es eine Flut an Informationen.

Abbildung 1: In der Standardeinstellung fällt Top zunächst eher schlicht aus.

Auf den ersten Blick finden sich in der Kopfzeile die Uhrzeit, die Uptime, die Zahl der angemeldeten User und die durchschnittliche Systemlast. Darunter folgen Statistiken zum CPU-Verbrauch. Hier lohnt es, sich mit den einzelnen Messgrößen zu befassen: Beispielsweise zeigt us den Anteil der Benutzerprozesse, deren Priorität nicht durch Nice angepasst wurde (siehe Kasten “Umgekehrte Sympathie”). Den Anteil der Kernel-Prozesse liefert sy. Statistiken zum Hauptspeicher fordern Sie mit dem Kommando free an.

Die wichtigste Rolle in Top spielt die dritte Spalte, die den belegten Speicher beziffert. Trotzdem sollten Sie auch die Spalte buff/cache im Auge behalten. Ein hoher Belegungsgrad des Speichers führt nicht zwangsläufig zu Problemen. Der Linux-Kernel hält Binaries im Speicher, bei denen er Wiederverwendungspotenzial sieht. Erneut gestartete Prozesse, die auf noch nicht im Buffer/Cache-Bereich liegende Bibliotheken zurückgreifen, lassen sich dadurch erheblich schneller anstoßen.

Buffer/Cache ist aber gleichzeitig sehr volatil: Sollten sich Speicherengpässe andeuten, setzt der Kernel diesen Bereich innerhalb kürzester Zeit erneut ein. Ein gut gefüllter Buffer/Cache-Bereich ist demnach sehr zu begrüßen, Sie sollten ihn bei der Gesamtbelegung des RAMs immer mit berücksichtigen.

Den bei Weitem größten Teil der Ausgabe von Top macht die Prozessliste aus, auf die ich später zurückkomme.

Top anpassen

Wenn Sie in Top ein Fragezeichen eingeben, landen Sie bei einer ziemlich schwierig zu lesenden Hilfe (Abbildung 2). Richtig angewandt ermöglicht sie aber trotzdem spannende Anpassungen.

Abbildung 2: Die Hilfe zu Top glänzt nicht gerade durch Lesefreundlichkeit.

Mit einem Druck auf [Umschalt]+[Z] erreichen Sie ein Menü, in dem Sie die einzelnen Anzeigen farbig gestalten. Mit [Z]+ aktivieren Sie die Einfärbung, mit [W]+ speichern Sie die Änderungen an Top in die Datei .toprc. So behält das Tool Ihre Einstellungen permanent bei. [M]+ sortiert nach Memory, [P]+ nach Prozessorlast. Das Kleiner-Zeichen ([<]) verschiebt das Sortierfeld nach links, das Größer-Zeichen ([Umschalt]+[<]) nach rechts.

Durch einen Druck auf [F] wechseln Sie ins Fields-Management-Menü (Abbildung 3). Hier lassen sich beliebige Spalten wie SWAP ein- und ausblenden. Das erweist sich mitunter als überaus nützlich; zum Beispiel um auf einem Server herauszufinden, wohin der Swapspace verschwunden ist. Über die Pfeiltasten nach oben und unten steuern Sie einzelne Felder an, die Sie mit der Leertaste (de-)aktivieren. Mit den Pfeiltasten nach links und rechts wählen Sie das zu verschiebende Feld aus.

Abbildung 3: Innerhalb des Fields Management richten Sie die Spalten nach Belieben ein.

Sortieren Sie nun mit [M] nach Speicherbedarf und drücken anschließend [Umschalt]+[<], sortiert das die Prozessliste, wie in Abbildung 4 gezeigt, nach SWAP. Mit diesen Infos kann ein Admin unter Umständen einige Prozesse recyclen, sodass die Maschine bis zur nächstmöglichen Downtime nicht rebootet werden muss.

Abbildung 4: Richtig aktiviert, sollte das Feld SWAP rechts neben dem Bereich %MEM auftauchen.

Lasten erkennen

Ein stark unterschätzter und häufig falsch verstandener Bestandteil in Top sind die drei Werte für load average (in Abbildung 1 rechts oben). Sie geben die durchschnittliche Systemlast in der letzten Minute, den letzten 5 Minuten und den letzten 15 Minuten an.

Zur Systemlast unter Linux sollten Sie wissen: Ein System, das nichts tut, weist eine Systemlast von 0 auf. Jeder Prozess, der gerade ausgeführt wird oder darauf wartet, erhöht die Systemlast um 1. Dasselbe gilt für Prozesse, die auf Disk-I/O warten. Das heißt: Zeigt ein System beispielsweise eine Last von 1.10, 0.75, 4.33 an, war es in der letzten Minute mit 10 Prozent überlastet, über die letzten 5 Minuten zu 25 Prozent im Leerlauf, und in den vergangenen 15 Minuten warteten mehr als drei Prozesse auf Ausführung.

Demnach ächzte das System stark unter Last – vorausgesetzt, es handelt sich um ein Single-Core-System. Auf einem Dual-Core-Rechner würden dieselben Zahlen etwas ganz anderes bedeuten: In der letzten Minute war eine CPU zu 90 Prozent unbeschäftigt, in den letzten 5 Minuten lief die Maschine zu 62,5 Prozent im Leerlauf, und in den letzten 15 Minuten war sie mit je gut einem wartenden Prozess pro CPU überlastet. Insgesamt ist für mich load average der Hauptindikator, um Systemüberlast zu identifizieren.

Wie bereits erwähnt, steigt die Systemlast nicht nur bedingt durch Auslastung der CPU-Kerne. Sie vergrößert sich auch dann, wenn ein NFS-Server nicht antwortet und Sie von der lokalen Maschine etwa mit Df (“disk free”) den verfügbaren Festplattenspeicher überprüfen: Der Kernel schiebt Df in die Warteschleife und erhöht damit die Last um den Wert 1.

Erfolgt so etwas im Rahmen eines Monitorings, etwa, wenn ein bestimmter Sensor alle 30 Sekunden die Festplattenbelegung prüft, kann der Ausfall eines NFS-Servers schnell unangenehme Folgen nach sich ziehen. Ich erinnere mich an Fälle, in denen auf einer Quad-Core-Maschine die load average auf über 350 in den letzten 15 Minuten stieg. Als Ursache entpuppte sich ein ausgefallener NFS-Server. Hier hilft nur, den jeweiligen Einhängepunkt mithilfe des Befehls umount -l -f /my/nfs/mountpoint forciert auszuhängen – sofern das System dazu noch in der Lage ist.

Bei ungewöhnlich hoher Last lege ich Ihnen zudem ans Herz, sich mit Dmesg (“display message”) zu beschäftigen. Der Aufruf dmesg gibt die Meldungen des Kernel-Ringpuffers auf dem Bildschirm aus. Hier erhalten Sie oft wertvolle Hinweise auf die Wurzel des Performance-Übels. Möchten Sie dabei lesbare Zeitstempel sehen, starten Sie Dmesg mit dem Parameter -T.

Tiefer bohren

Hilft Top nicht weiter, kommt Vmstat ins Spiel, das ebenfalls einen Schnappschuss der wichtigsten Systemressourcen erzeugt (Abbildung 5). Dabei sollten Sie vor allem die Spalten bi für “Bytes in” und bo für “Bytes out” unter die Lupe nehmen. Dahinter stecken die geschriebenen und gelesenen Bytes von Blockgeräten wie Festplatten. Je höher die hier aufgelisteten Werte ausfallen, umso mehr I/O-Transaktionen finden statt. Ähnliches gilt für si und so: Sie geben Auskunft über das Aus- und Einlagern von Speicherinhalten in den Swapspace. Hohe Werte an dieser Stelle, kombiniert mit starker Speicherauslastung, sind ein eindeutiges Zeichen für Speicherknappheit.

Abbildung 5: Vmstat liefert unter anderem die Anzahl der I/O-Transaktionen.

Wenn Sie mittels Top und Vmstat herausgefunden haben, dass I/O das System ausbremst, lautet die nächste Adresse Iotop. Wie Top listet das Werkzeug Statistiken zu den I/O-Werten der jeweiligen Prozesse auf. Eine kurze Hilfe am unteren Ende der Ausgabe erläutert die vorhandenen Optionen. Für mich sind die Pfeiltasten elementar, mit denen ich das Sortierfeld verschieben und prüfen kann, welche Prozesse besonders viele Lese- oder Schreibaktionen auf den Festplattenspeicher ausführen. Allerdings findet sich Iotop nicht notwendigerweise vorinstalliert auf dem System. Unter Debian behebt das Kommando sudo apt install iotop den Mangel.

Eingespieltes Team

Nehmen wir nun einmal an, Sie wundern sich über die schlechte Performance Ihrer persönlichen WordPress- oder Nextcloud-Instanz: Zunächst offenbart Top eine hohe Systemlast; der Hauptspeicher ist vollständig ausgelastet, der Swapspace schon beträchtlich gefüllt. Daraufhin liefert Vmstat extrem hohe Werte für Disk-I/O und Swap-I/O. Mit Iotop enttarnen Sie schließlich die Datenbank als Übeltäter, die zu viel RAM nutzt und damit in den Swapspace läuft.

In Top finden Sie heraus, dass die Datenbank den größten Teil des Hauptspeichers belegt und kaum Ressourcen für etwa PHP-Prozesse übrig lässt. Als Ursache dafür kommt zweierlei infrage: Zum einen könnte eine Fehlkonfiguration vorliegen; vielleicht haben Sie der Datenbank zu viel Speicher zugewiesen. Zum anderen benötigt die Datenbank häufig wegen ihres natürlichen Wachstums mehr Speicher. Hier wäre es nun wichtig, weiter zu recherchieren.

Fazit

Mit den richtigen Werkzeugen und einem systematischen Vorgehen erweist es sich als relativ einfach, Engpässe auf einer Linux-Maschine zu identifizieren und zu beheben. Idealerweise befassen Sie sich schon vorab mit den Werkzeugen Ihrer Wahl, und nicht erst dann, wenn es zu Problemen kommt. Darüber hinaus schadet es sicherlich nicht, mit Top, Vmstat und Iotop zu experimentieren und die Auswirkungen bestimmter Kommandos zu überwachen. Ganz nebenbei lernen Sie dadurch viel über die Kapazitäten Ihres Systems. (csi)