Wenn Sie lange genug als Systemadministrator gearbeitet haben, haben Sie die gefürchteten „Server ist langsam“-Vorfälle gesehen. Lange Zeit bereiteten mir solche Vorfälle ein flaues Gefühl im Magen. Wie zum Teufel beheben Sie etwas so Subjektives? Die "Verlangsamung" eines normalen Benutzers kann einfach durch andere Prozesse (geplant oder nicht) verursacht werden, die ausgeführt werden und mehr Ressourcen als gewöhnlich verbrauchen, oder es könnte tatsächlich etwas mit dem Server nicht stimmen.
Als ich anfing, als Systemadministrator zu arbeiten, antwortete ich sofort mit:"Ich brauche mehr Informationen dazu." Nun, normalerweise kann der Benutzer keine weiteren Informationen geben, weil er nicht weiß, was hinter den Kulissen läuft oder wie er erklären soll, was er sieht, außer „es ist nur langsam“. Heutzutage überprüfe ich ein paar Dinge, bevor ich dem Benutzer überhaupt antworte.
Erste Anmeldung
Es gibt eine Menge, die Sie erkennen können, wenn Sie sich beim Host anmelden. Kannst du dich überhaupt einloggen? Ist die Anmeldung langsam oder hängt sie? Die ssh Der Befehl hat drei Debug-Ebenen, von denen jede Ihnen eine Fülle von Informationen liefert, bevor Sie sich überhaupt auf dem System befinden. Um Debugging zu aktivieren, fügen Sie einfach ein zusätzliches v hinzu zum -v Möglichkeit. Ein Level-3-Debug, das ich ausschließlich verwende, wäre beispielsweise:
[~]$ ssh -vvv hostname.domain.com
Die „Big 3“ (auch bekannt als CPU, RAM und Festplatten-E/A)
Schauen wir uns nun die drei größten Ursachen für Server-Verlangsamungen an:CPU, RAM und Festplatten-I/O. Die CPU-Auslastung kann zu einer allgemeinen Verlangsamung des Hosts und zu Schwierigkeiten bei der rechtzeitigen Ausführung von Aufgaben führen. Einige Tools, die ich verwende, wenn ich mir die CPU anschaue, sind top undsar .
Überprüfen der CPU-Auslastung mit top
Die top Dienstprogramm gibt Ihnen einen Echtzeit-Überblick darüber, was auf dem Server vor sich geht. Standardmäßig, wenn top startet, zeigt es Aktivität für alle CPUs:
Diese Ansicht kann durch Drücken der Zifferntaste 1 geändert werden, wodurch weitere Details zu den Nutzungswerten für jede CPU hinzugefügt werden:
Einige Dinge, auf die Sie in dieser Ansicht achten sollten, sind der Lastdurchschnitt (angezeigt auf der rechten Seite der obersten Zeile) und der folgende Wert für jede CPU:
us:Dieser Prozentsatz stellt die Menge an CPU dar, die von Benutzerprozessen verbraucht wird.sy:Dieser Prozentsatz stellt die Menge an CPU dar, die von Systemprozessen verbraucht wird.id:Dieser Prozentsatz stellt dar, wie untätig jede CPU ist.
Jeder dieser drei Werte kann Ihnen in Echtzeit eine ziemlich gute Vorstellung davon geben, ob CPUs von Benutzerprozessen oder Systemprozessen gebunden sind.
Um den Lastdurchschnitt wirklich zu erklären, wäre ein eigener Artikel erforderlich. Für die Zwecke dieses Artikels werde ich allgemein sprechen. Die drei Lastdurchschnittswerte von links nach rechts repräsentieren Ein-Minuten-, Fünf-Minuten- und 15-Minuten-Durchschnittswerte. Nochmal sehr gesprochen Im Allgemeinen, wenn Sie sehen, dass der Ein-Minuten-Durchschnitt die Anzahl Ihrer physischen CPUs übersteigt, ist das System höchstwahrscheinlich CPU-gebunden.
Hinweis: Weitere Informationen zum Ladedurchschnitt und warum manche Leute denken, dass es sich um eine dumme Zahl handelt, finden Sie in Brendan Greggs ausführlicher Recherche.
Checking-all-of-the-big-3-with-sar
Für historische CPU-Leistungsdaten verlasse ich mich auf den sar Befehl, der von sysstat bereitgestellt wird Paket. Auf den meisten Serverversionen von Linux ist sysstat ist standardmäßig installiert, aber wenn dies nicht der Fall ist, können Sie es mit dem Paketmanager Ihrer Distribution hinzufügen. Der sar sammelt Systemdaten alle 10 Minuten über einen Cron-Job, der sich in /etc/cron.d/sysstat befindet (CentOS 7.6). So überprüfen Sie alle "Big 3" mit sar .
Hinweis: Wenn Sie gerade sar installiert haben Um diesem Artikel zu folgen, geben Sie dem Befehl etwas Zeit, um zuerst Daten aufzuzeichnen.
Der Befehl sar -u gibt Ihnen Informationen über alle CPUs auf dem System, beginnend um Mitternacht:
Wie bei top , die wichtigsten Dinge, die hier überprüft werden müssen, sind %user , %system , %iowait , und %idle . Diese Informationen können Ihnen sagen, wie lange der Server Probleme hatte.
Insgesamt ist der sar Der Befehl kann viele Informationen liefern. Da dieser Artikel nur einen kurzen Überblick darüber gibt, was auf dem Server passiert, schauen Sie sich man sar an um diese Informationen noch weiter aufzuschlüsseln.
Um die RAM-Leistung zu überprüfen, verwende ich sar -r , die Ihnen die Speichernutzung des Tages anzeigen:
Das Wichtigste, worauf Sie bei der RAM-Nutzung achten sollten, ist %memused und %commit . Ein kurzes Wort zum %commit Feld:Dieses Feld kann über 100 % anzeigen, da der Linux-Kernel RAM routinemäßig überbelegt. Wenn %commit konstant über 100 % liegt, könnte dieses Ergebnis ein Indikator dafür sein, dass das System mehr RAM benötigt.
Für die Festplatten-E/A-Leistung verwende ich sar -d , wodurch Sie die Festplatten-E / A-Ausgabe nur mit dem Gerätenamen erhalten. Um den Namen der Geräte zu erhalten, verwenden Sie sar -dP :
Sehen Sie sich für diese Ausgabe %util an und %await gibt Ihnen ein gutes Gesamtbild der Festplatten-E/A auf dem System. Der %util Feld ist ziemlich selbsterklärend:Es ist die Nutzung dieses Geräts. Das await Das Feld enthält die Zeit, die die E/A im Scheduler verbringt. Await wird in Millisekunden gemessen, und in meiner Umgebung habe ich gesehen, dass alles, was länger als 50 ms ist, Probleme verursacht. Dieser Schwellenwert kann in Ihrer Umgebung variieren.
Wenn einer dieser Befehle ein Problem anzeigt, können Sie zurückgehen, um zu sehen, wann die Serverprobleme begonnen haben, indem Sie sar {-u, -r, -d, -dP} -f /var/log/sa/sa<XX> (wobei XX ist der Tag des Monats, nach dem Sie suchen möchten).
An diesem Punkt habe ich normalerweise eine gute Vorstellung davon, was gerade auf dem Server passiert und was in den letzten 48 Stunden oder so passiert ist. Ich werde dem Benutzer mit fundierteren Antworten antworten. Zum Beispiel:„Ich sehe in den letzten 24 Stunden keinen Hinweis auf langsame Hosts. Bitte versuchen Sie, ein neues Putty-Profil für ssh zu verwenden ein und lassen Sie es mich wissen, wenn Sie weiterhin Probleme haben."
Ein weiteres Beispiel:„Ich sehe nichts, was derzeit Probleme auf diesem Host verursacht, aber ich habe eine höhere CPU-Last bemerkt $time . Haben Sie da Probleme gesehen? Wenn ja, versuchen Sie es bitte jetzt und lassen Sie es mich wissen, wenn weiterhin Probleme auftreten."
Du hast die Idee. Die Informationen erhalten, indem man sich die anfängliche Anmeldung ansieht und dann ein paar sar ausführt Befehle, für deren Ausführung ich im Allgemeinen weniger als 10 Minuten benötige, tragen viel dazu bei, mehr Fragen abzuwehren und schneller eine Lösung zu finden.