Gute Tools zur Systemfehlerbehebung sind alles. Großartige Werkzeuge sind jedoch schwerer zu finden. Glücklicherweise enthält Linux eine Fülle hervorragender Programme und Dienstprogramme, mit denen Sie Probleme mit dem Systemverhalten profilieren, analysieren und lösen können, von Anwendungsengpässen bis hin zu Fehlkonfigurationen und sogar Fehlern. Alles beginnt mit einem Tool, das die erforderlichen Metriken erfassen und Ihnen die benötigten Daten liefern kann.
Health-Check ist ein nettes Programm, das Prozesse überwachen und profilieren kann, sodass Sie eine übermäßige Ressourcennutzung – oder damit verbundene Probleme – identifizieren und beheben können. Wo es sich vom Rest der Masse abhebt - es zielt darauf ab, viele nützliche Facetten von Systemdaten gleichzeitig anzubieten, damit Sie Ihre Systeme einfacher nach Komponenten durchsuchen, Leistungsprobleme beheben und Konfigurationspannen in Ihrer Umgebung beheben können. Anstatt fünf Tools gleichzeitig auszuführen oder fünf Läufe durchzuführen, um alle benötigten Informationen zu erhalten, verwenden Sie einfach die Gesundheitsprüfung, und Bob ist Ihr entfernter Verwandter. Gut. In Ordnung, bereit? Fortfahren.
Gesundheitscheck in Aktion
Bevor wir das Dienstprogramm im Zorn ausführen, ein paar kleine Hinweise. Erstens benötigen Sie sudo-Berechtigungen, um dieses Tool auszuführen, obwohl Sie die eigentliche Anwendung im Kontext anderer Benutzer auf dem System ausführen können (mit dem Flag -u). Zweitens müssen Sie verstehen, wie Linux funktioniert, um die Ergebnisse nutzen zu können - ich habe eine ganze Reihe von Artikeln zu diesem Thema, die weiter unten verlinkt sind.
Im Wesentlichen vereint Health-Check, wie ich gerade skizziert habe, die Funktionalität einer Vielzahl von Programmen unter einem Dach. Es mischt auf schöne Weise Elemente, die Sie erhalten würden, wenn Sie netstat, lsof, vmstat, iostat ausführen, und untersucht verschiedene Strukturen unter /proc und /sys. Das ist so etwas wie dstat, das die Leistungsfähigkeit von vmstat, iostat und ifstat kombiniert. Sie können mit dem einfachen Lauf beginnen (Flag -b):
sudo ./health-check -u "user" -b "binary"
Selbst in diesem "kurzen" Modus wird viel ausgegeben, etwa so:
CPU-Auslastung (in Bezug auf 1 CPU):
Benutzer:34,24 %, System:13,30 %, Gesamt:47,54 % (hohe Auslastung)
Zunächst erhalten Sie grundlegende CPU-Zahlen, normalisiert pro Kern (100 % =1 voller Kern). Health-Check verfügt über interne Schwellenwerte, anhand derer angezeigt wird, ob es sich um eine niedrige, mittlere oder hohe Belastung handelt. Dies soll Ihnen nur einen Eindruck davon vermitteln, was Sie erwarten sollten. Die Einzelheiten hängen von der Art der Anwendung und der Workload ab, die Sie profilieren. Es gibt Unterschiede zwischen GUI- und Befehlszeilen-Tools, Software, die aus einer Datenbank liest, und einer, die dies nicht tut, Software mit einer großen Anzahl gemeinsam genutzter Bibliotheken, der Verwendung von Hardware usw.
Seitenfehler:
PID-Prozess Minor/sec Major/sec Total/sec
1043 google-chrome 16156.46 0.25 16156.71
Wir haben in der Vergangenheit ausführlich über Seitenfehler gesprochen (Links im weiterführenden Abschnitt unten). Wenn Sie nicht wissen, was Ihre Anwendung tun soll, sagen Ihnen die Zahlen allein nicht viel. Aber sie können für vergleichende Studien sehr nützlich sein, wie zwei verschiedene Programme des gleichen Typs oder zwei verschiedene Versionen des gleichen Programms oder das gleiche Programm, das auf zwei verschiedenen Plattformen läuft.
Kontextwechsel:
13687,53 Kontextwechsel/Sek. (sehr hoch)
Der Kontextwechselwert gibt an, wie oft der Kernel die Runqueue aufgibt und zwischen Tasks wechselt. Für interaktive Prozesse (wie den Browser), die eine benutzerinteraktive Komponente haben, möchten Sie eigentlich so viele Kontextwechsel wie möglich (die Aufgaben werden so wenig wie möglich ausgeführt), weil Sie nicht möchten, dass diese Aufgaben den Prozessor in Beschlag nehmen. Tatsächlich ist eine lange Berechnung ein Zeichen für Batch-Jobs. Hier könnte ein geringer Kontextwechsel ein Hinweis auf ein Problem mit einer interaktiven (GUI) Anwendung wie dem Browser sein.
Datei-E/A-Vorgänge:
E/A-Vorgänge pro Sekunde:312,80 Öffnen, 283,49 Schließen, 768,71 Lesen,
410,83 Schreiben
Die E/A-Werte sind nützlich, wenn Sie eine Basislinie haben, und sie hängen auch vom zugrunde liegenden E/A-Stack ab, einschließlich der Hardware, des Busses, des Treibers, der Dateisystemauswahl und aller anderen Festplattenoperationen, die gleichzeitig ausgeführt werden.
Anrufanalyse des Polling-Systems:
google-chrome (1043), Umfrage:
1555 Anrufe mit sofortiger Zeitüberschreitung ohne Zeitüberschreitung (nicht blockierende Peeks)
1 wiederholte Anrufe mit Zeitüberschreitung ungleich Null timeouts
(light polling)
1125 wiederholte, sofort abgelaufene abgefragte Anrufe ohne timeouts
(heavy polling peeks)
Dieser Abschnitt ist ein weiterer Indikator für eine mögliche Benutzerinteraktivität der profilierten Binärdatei. Polling-Systemaufrufe sind Systemaufrufe, die darauf warten, dass Dateibeschreibungen zur Ausführung von E/A-Operationen bereit werden. Normalerweise zeigt dies Netzwerkverbindungen an. Wir werden dies genauer untersuchen, wenn wir einen vollständigen Durchlauf durchführen.
Speicher:
Speicheränderung (K/Sekunde):
PID Prozesstyp Größe RSS PSS
1043 Google-Chrome Stack 32,51 27,59 27,59 (wächst
mäßig schnell)
1043 google-chrome Heap 67550,94 9092,51 9112,70 (wächst sehr
schnell)
1043 google-chrome Mapped 102764,33 27296,24 18781,80 (wächst sehr
schnell)
Für die meisten Menschen und die meisten Anwendungstypen werden Speicheroperationen nicht so interessant sein. Arbeitsspeicherintensive Workloads sind in Desktop-Software nicht so üblich. Sie können für Datenbanken und komplexe Berechnungen sehr wichtig sein, was Sie normalerweise auf einem System der Serverklasse tun würden. Aber diese Zahlen können verwendet werden, um Unterschiede zwischen Plattformen, Kerneln und Softwareversionen zu untersuchen.
Offene Netzwerkverbindungen:
PID Process Proto Send Receive Address
1043 google-chrome UNIX 531,52 K 35,16 K /run/user/1000/bus
1043 google-chrome UNIX 0,00 B 88,56 K /run /systemd/journal/...
1043 Google-Chrom 64,51 K 0,00 B-Sockel:[2737924]
1043 Google-Chrom 30,55 K 0,00 B-Sockel:[2746558]
1043 Google-Chrom 3,98 K 0,00 B Buchse:[2742865]
...
Der Zahlensatz der Netzwerkverbindungen liefert Ergebnisse, die denen von netstat und lsof ähneln, aber Sie erhalten auch die Sende-/Empfangswerte, was sehr nützlich sein kann. Wenn Sie wissen, was das Programm im Netzwerk tun soll, können Sie seine Ausführung profilieren und nach möglichen Fehlkonfigurationen im Netzwerkstapel suchen.
Längerer (detaillierter) Lauf
Sie können sich auch für weitere Statistiken entscheiden (z. B. mit -c -f Flags, ohne -b Flag). Sie erhalten erweiterte Ergebnisse für jeden der Abschnitte, die wir zuvor besprochen haben, und dies kann Ihnen zusätzliche Einblicke in das Verhalten Ihrer Software geben. Wenn Sie untergeordnete Prozesse und Gabeln verfolgen, können Sie die Ausführungsreihenfolge sehen. CPU-Statistiken werden basierend auf der Nutzung aufgelistet, wobei die häufigsten Übeltäter ganz oben stehen.
CPU-Auslastung (in Bezug auf 1 CPU):
PID-Prozess USR% SYS% TOTAL% Dauer
1715 vlc 47,04 8,17 55,21 14,71 (hohe Last)
1720 vlc 46,91 7,96 54,87 14,43 (hohe Last )
1723 vlc 46,77 7,96 54,74 14,35 (hohe Belastung)
...
1721 vlc 1,69 1,08 2,77 1,21 (leichte Belastung)
1722 vlc 0,20 0,07 0,27 0,16 (sehr geringe Belastung )
1726 vlc 0.07 0.00 0.07 0.02 (sehr geringe Last)
1742 vlc 0.00 0.00 0.00 0.07 (Leerlauf)
1732 vlc 0.00 0.00 0.00 0.02 (Leerlauf)
1728 vlc 0.0.0 0.00 0.00 0,00 0,06 (Leerlauf)
1719 vlc 0,00 0,00 0,00 0,06 (Leerlauf)
Gesamt 971,80 161,72 1133,52 (CPU voll ausgelastet)
Im obigen Beispiel haben wir beim Ausführen von VLC (mit einer HD-Clip-Wiedergabe von etwa 14 Sekunden) 1.133 % der CPU-Zeit verwendet, was 11,33 CPU-Kernen entspricht. Das klingt viel, aber da das System über acht Kerne (Threads) verfügt, bedeutet dies effektiv, dass nur 1,5 Kerne tatsächlich für das Video verwendet wurden. Es wäre auch interessant zu wissen, welche Kerne tatsächlich verwendet wurden.
Kontextwechsel:
PID-Prozess Freiwillige Unfreiwillige Summe
Ctxt Sw/Sec Ctxt Sw/Sec Ctxt Sw/Sec
1744 vlc 2500,09 1,15 2501,24 (hoch)
1723 vlc 1493,47 1,82 1495,29 ( hoch)
1740 vlc 1224,03 3,31 1227,33 (hoch)
1717 vlc 947,43 0,40 947,84 (ziemlich hoch)
1731 vlc 736,37 0,81 737,18 (ziemlich hoch)
Für Seitenfehler gibt es nichts Neues. Bei Kontextwechseln erhalten wir auch eine Liste von freiwilligen und unfreiwilligen CS. Das letztere Bündel kann ein Hinweis darauf sein, dass Tasks ihren zugewiesenen Slice überschreiten, was dann dazu führen würde, dass sie bei der nächsten Ausführung eine niedrigere dynamische Priorität haben (was für interaktive Prozesse nicht gut ist).
Datei-E/A-Operationen:
PID Process Count Op Dateiname
1715 vlc 176 R /home/roger/developers.webm
1715 vlc 48 C /etc/ld.so.cache
1715 vlc 48 O /etc/ld.so.cache
1715 vlc 34 R /usr/share/X11/locale/locale.alias
Die Datei-I/O zeigt jetzt auch die Anzahl der Operationen pro Prozess, die Art der Operation sowie den Dateinamen an. Dies muss keine tatsächliche Datei auf der Platte sein, dies könnte auch ein Bus sein. Die verfügbaren Operationen sind am Ende dieses Abschnitts abgedruckt. Wie genau die Lese- und Schreibvorgänge durchgeführt werden, hängt von vielen Faktoren ab.
...
1715 vlc 1 C /lib/x86_64-linux-gnu/libnss_systemd.so.2
1715 vlc 1 ODER /usr/bin/vlc
Insgesamt 4352
Op :O=Öffnen, R=Lesen, W=Schreiben, C=Schließen
Sie erhalten auch die Häufigkeit dieser I/O-Operationen:
Datei-E/A-Vorgänge pro Sekunde:
PID-Prozess Öffnen Schließen Lesen Schreiben
1715 vlc 100,57 96,72 89,77 1,75
1719 vlc 3,24 4,99 3,04 0,00
...
Im nächsten Abschnitt geht es um Systemaufrufe, und er ist sehr detailliert. Die Ausgabe ist ähnlich wie bei strace. Sie haben die Prozess-ID, den Prozessnamen, den Systemaufruf, die Anzahl, die Rate, die Gesamtzeit (in uns) und den Prozentsatz, den jeder Systemaufruf von der Gesamtausführungszeit genommen hat. Sie können diese Zahlen nicht interpretieren, es sei denn, Sie wissen, was die Anwendung tun soll, oder Sie können sie mit einer Baseline vergleichen.
Nachverfolgte Systemaufrufe:
PID Process Syscall Count Rate/Sec Total uSecs % Call Time
1715 vlc stat 429 28.9555 3004 0.0011
1715 vlc mmap 240 16.1989 4912 0.0017
1715 vlc mprotect 203 13,7015 4739 0,0017
...
Die Informationen sind nützlicher, wenn Sie sich Polling-Systemaufrufe ansehen. Der Kürze halber habe ich die Ausgabe unten leicht bearbeitet. Die letzten vier Felder zeigen alle Timeouts an, z. B.:Zero Timeout, Minimum Timeout usw. Im Wesentlichen geben sie Ihnen einen Indikator dafür, wie viel Zeit es gedauert hat, bis diese Systemaufrufe abgeschlossen waren. Das Feld Unendliche Anzahl bezieht sich auf Systemaufrufe, die eine unendliche Wartezeit hatten (für die Dauer des Anwendungslaufs). Die Informationen werden auch als Histogramm pro Prozess angezeigt, von null bis unendlich, logarithmisch gebuckelt, bis zu 10 us, 10–99 us, 100–99 us und so weiter.
Top Polling-Systemaufrufe:
PID Process Syscall Rate/Sec Inf Zero Min Max Avg
1715 vlc poll 3.2398 45 1 0.0 s 25.0 s 1.0 s
1715 vlc rt_sigtimed 0.1350 2 0 0.0 s 0.0 s 0,0 s
1717 vlc poll 124.7312 5 1 0,0 s 30,0 s 958,4 ms
...
Das detailliertere Ausgabeprotokoll enthält auch die Dateisystem-Synchronisierungsdaten.
Dateisystemsynchronisierungen:
PID fdatasync fsync sync syncfs total total (Rate)
1723 0 2 0 0 2 0,13
Dateien synchronisiert:
PID syscall # syncs Dateiname
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.lock
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.XM1715
Schließlich enthält die detaillierte Ausgabe auch Speicher- und Netzwerkverbindungsinformationen, aber der Hauptunterschied besteht in den Ergebnissen, die pro Prozess angezeigt werden. Wie wir bereits besprochen haben, ist Ersteres normalerweise für die meisten Desktop-Arbeitslasten nicht nützlich (es sei denn, Sie sind der Entwickler des Programms), während Letzteres nützlich sein kann, um Probleme im Netzwerkstapel zu finden.
Die Zustandsprüfung erstellt eine ziemlich große Menge an Ergebnissen, bietet jedoch viele Einblicke in das Verhalten Ihrer Anwendungen. Sie können die Verwendung mit anderer Software kombinieren, um eine vollständige Analyse Ihrer Software zu erhalten und Leistungsprobleme zu beheben. Health-Check kann auch laufende Aufgaben profilieren (Flag -p), was es als Ergänzung zu Ihrer Problemlösungs-Toolbox sehr praktisch macht.
Manuelle Einrichtung
Wenn Sie mit der in den Repos verfügbaren Version nicht zufrieden sind, können Sie manuell kompilieren. Ein weiterer Grund, dies zu tun, besteht darin, mögliche Probleme zu umgehen, die ältere Versionen haben könnten, wie zum Beispiel den Timer_stats-Fehler, bei dem die Tools versuchen, auf /proc/timer_stats zuzugreifen, aber diese Struktur in neueren Kerneln nicht mehr verfügbar ist:
Kann /proc/timer_stats nicht öffnen.
In der Tat, wenn Sie das überprüfen, erhalten Sie:
cat /proc/timer_stats
cat:/proc/timer_stats:Keine solche Datei oder Verzeichnis
Führen Sie zum Kompilieren Folgendes aus:
git clone https://kernel.ubuntu.com/git/cking/health-check.git/
cd health-check
make
Möglicherweise wird der folgende Fehler angezeigt:
json.h:25:10:schwerwiegender Fehler:json-c/json.h:Keine solche Datei oder Verzeichnis
#include
Das bedeutet, dass Ihnen das Entwicklungspaket für JSON fehlt, das das Tool zum erfolgreichen Kompilieren benötigt. Der tatsächliche Name des Pakets variiert von einer Distribution zur anderen, aber in meinem Test auf Kubuntu hat das Folgende den Kompilierungsfehler behoben:
sudo apt-get install libjson-c-dev
Mehr lesen
Wenn Sie an zusätzlichen Tools zur Systemfehlerbehebung interessiert sind, dann:
Linux-Super-Duper-Verwaltungstools:strace
Linux-Super-Duper-Verwaltungstools:lsof
Linux-Super-Duper-Verwaltungstools:gdb
Langsames System? Perf zur Rettung!
Super-Tutorial zum Debuggen von Linux-SystemenCoole Linux-Hacks - Teile eins bis vier - verlinke nur den letzten.
Last but not least, mein Buch zur Problemlösung!
Schlussfolgerung
Der Gesundheitscheck ist ein sehr nützliches und praktisches Instrument. Es ersetzt nicht strace oder netstat oder perf, aber es kann Ihnen sicher dabei helfen, eine sehr genaue mehrdimensionale Momentaufnahme dessen zu erhalten, was Sie profilieren. Dies ist ein sehr guter erster Schritt, der Sie in die richtige Richtung weisen kann. Sie können dann ein Dienstprogramm auswählen, das speziell die relevante Facette der Softwareausführung untersucht (z. B. Wireshark für das Netzwerk oder Valgrind für den Speicher). In gewisser Weise wird der Gesundheitscheck dadurch zu einem Alleskönner.
Sie müssen wissen, wie Linux-Systeme funktionieren - und welche Anwendung Sie ausführen. Aber auch wenn Sie dieses Wissen nicht haben, kann Health-Check für vergleichende Studien und die Fehlersuche bei Leistungsengpässen verwendet werden. Wenn Sie wissen, dass etwas nicht so gut läuft, wie es sollte, können Sie es einmal auf einem guten System, einmal auf einem schlechten (betroffenen) System nachverfolgen und dann die beiden vergleichen. Die vielen Arten von Daten, die der Gesundheitscheck bereitstellt, werden bei der Lösung des Problems sehr hilfreich sein. Und das bringt uns zum Ende dieses Tutorials. Mit etwas Glück haben Sie etwas Neues gelernt, und es war auch eine angenehme Fahrt. Pass auf dich auf.