Leistungsoptimierung meistern: Ein praktischer Leitfaden zur Nutzung des Sysstat-Toolkits

Performance-Arbeit wird unübersichtlich, wenn man nur den aktuellen Moment betrachtet. Ein Server ist jetzt langsam, aber war er vor zehn Minuten auch langsam? Hat die Festplatte begonnen, sich zu stauen, bevor die CPU anstieg? Begann das Problem nach dem Cron-Job, dem Deployment oder dem Backup-Fenster? Das sysstat-Toolkit ist nützlich, weil es sowohl Live-Messwerte als auch einen historischen Datensatz liefert, mit dem Sie vergleichen können.

Das Hauptwerkzeug ist sar, der System Activity Reporter. Ich greife darauf zurück, wenn top zu kurz ist, wenn ein Vorfall bereits vorbei ist oder wenn ich zeigen muss, dass ein Problem Speicher, Speicherdruck, Netzwerkverkehr oder CPU-Sättigung war, anstatt anhand von Symptomen zu raten. Der Rest der Suite, insbesondere iostat und mpstat, füllt Details aus, wenn sar auf einen wahrscheinlichen Engpass hindeutet.

Dies ist kein Ersatz für vollständige Beobachtbarkeit. Sie brauchen weiterhin Anwendungsmetriken, Protokolle, Tracing und externe Prüfungen. Aber auf einem Linux-Host ist sysstat einer der schnellsten Wege, um die erste praktische Frage zu beantworten: Was hat die Maschine tatsächlich getan?

1. Installation und Erstkonfiguration von Sysstat

Das sysstat-Paket ist normalerweise in den Standard-Repositorien aller großen Linux-Distributionen verfügbar.

1.1 Installationsbefehle

Verwenden Sie den für Ihr System geeigneten Paketmanager-Befehl:

Debian/Ubuntu:

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora:

sudo yum install sysstat
# oder verwenden Sie dnf für neuere Systeme
sudo dnf install sysstat

1.2 Aktivieren der historischen Datenerfassung

Damit sar wirklich nützlich ist, muss es Daten historisch erfassen. Standardmäßig richtet die Installation oft einen Cron-Job oder einen systemd-Timer ein, aber die Überprüfung ist entscheidend.

Stellen Sie auf modernen Systemen sicher, dass der sysstat-Dienst aktiv ist:

sudo systemctl enable --now sysstat

Konfigurationsdatei

Die Häufigkeit der Datenerfassung wird durch Konfigurationsdateien gesteuert, die sich normalerweise unter /etc/default/sysstat (Debian/Ubuntu) oder /etc/sysconfig/sysstat (RHEL/CentOS) befinden. Suchen Sie nach der Einstellung ENABLED oder HISTORY. Das Setzen von ENABLED="true" stellt die tägliche Datenerfassung sicher.

Tipp: Standardmäßig werden sysstat-Datendateien in /var/log/sa/ mit Dateinamen wie saXX gespeichert, wobei XX der Tag des Monats ist. Einige Debian-basierte Systeme legen Berichte auch unter /var/log/sysstat/ ab. Überprüfen Sie die Paketstandards, bevor Sie den Pfad annehmen.

Nachdem Sie die Erfassung aktiviert haben, warten Sie mindestens ein Intervall und bestätigen Sie, dass Dateien erscheinen:

ls -lh /var/log/sa/

Wenn das Verzeichnis leer ist, überprüfen Sie die systemd-Timer:

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

Auf älteren Systemen kann die Erfassung immer noch von Cron gesteuert werden. Die genaue Paketierung variiert je nach Distribution. Überprüfen Sie dies, anstatt sich auf das Gedächtnis von einem anderen Server zu verlassen.

2. Das Kernwerkzeug: System Activity Reporter (sar)

sar ist die primäre Schnittstelle zum Anzeigen von Statistiken. Es kann Echtzeitdaten anzeigen oder zuvor erfasste historische Daten analysieren.

2.1 Grundlegende Syntax für Echtzeit-Überwachung

Die grundlegende Syntax ist darauf ausgelegt, bestimmte Metriken in einem festgelegten Intervall für eine definierte Anzahl zu melden.

sar [optionen] [intervall] [anzahl]

Beispiel: Um allgemeine CPU-Statistiken alle 3 Sekunden, 10 Mal zu melden:

sar -u 3 10

Dieser Befehl ist während eines Vorfalls gut, weil er eine kurze, sich bewegende Stichprobe liefert, anstatt nur eine Momentaufnahme. Eine einzelne Zeile kann eine ruhige Sekunde erfassen und in die Irre führen. Zehn Stichproben über dreißig Sekunden zeigen, ob das Muster stetig, spitz oder bereits verschwunden ist.

Option	Beschreibung
-u	CPU-Auslastung (Standard)
-r	Speicher- und Paging-Statistiken
-d	Blockgeräteaktivität (Festplatten-I/O)
-n	Netzwerkstatistiken (z. B. -n DEV für Schnittstellenstatistiken)
-q	Run-Queue und Durchschnittslast
-W	Auslagerungsaktivität (Paging)
-A	Alle Metriken (nützlich für umfassende Momentaufnahmen)

Für historische Dateien ist die Form dieselbe. Sie fügen -f hinzu, um die Datendatei auszuwählen, und oft -s und -e, um den Zeitbereich einzuschränken. Das ist wichtig, weil das Lesen eines ganzen Tages Ausgabe während einer Störung langsam und verrauscht ist.

3. Wichtige Leistungsmetriken und praktische sar-Beispiele

Das Verständnis der Ausgabe von sar erfordert Kenntnisse darüber, welche Metriken auf Leistungsgesundheit oder -stress hinweisen.

3.1 CPU-Auslastung (sar -u)

Die CPU-Auslastung ist oft der erste Ort, an dem man nach Engpässen sucht. Eine hohe Auslastung in bestimmten Kategorien gibt Aufschluss über die Art der Arbeitslast.

sar -u 5 3

Metrik	Beschreibung	Engpassindikator
%user	CPU-Zeit, die für die Ausführung von Benutzerprozessen aufgewendet wird.	Hoch deutet auf Anwendungs-/Dienstsättigung hin.
%system	CPU-Zeit, die für die Ausführung von Kernel-/Systemaufgaben aufgewendet wird.	Hoch deutet auf intensive Systemaufrufe oder Treiberprobleme hin.
%iowait	CPU-Zeit, die im Leerlauf auf I/O-Operationen (Festplatte/Netzwerk) wartet.	Hoch deutet auf einen I/O-Engpass hin, nicht auf CPU-Mangel.
%idle	CPU-Zeit, die damit verbracht wird, auf nichts zu warten (verfügbar).	Niedrig (z. B. < 5%) deutet auf CPU-Sättigung hin.

Seien Sie vorsichtig mit %iowait. Es wird oft fälschlicherweise als "die CPU ist mit der Festplatte beschäftigt" gelesen. Es bedeutet tatsächlich, dass die CPU im Leerlauf war, während mindestens eine I/O-Anforderung ausstand. Ein hoher Wert kann auf Speicherlatenz hindeuten, muss aber mit Festplattenmetriken bestätigt werden. Auf einem Datenbankserver zum Beispiel ist ein hoher %iowait plus eine hohe Festplatten-await ein viel stärkeres Signal als %iowait allein.

Eine weitere nützliche CPU-Ansicht ist die Run-Queue:

sar -q 5 5

runq-sz zeigt, wie viele Aufgaben darauf warten, ausgeführt zu werden. Wenn die Durchschnittslast hoch ist, aber runq-sz bescheiden und %iowait hoch ist, haben Sie es möglicherweise mit blockiertem I/O und nicht mit reinem CPU-Druck zu tun. Wenn runq-sz hoch bleibt und %idle nahe Null ist, braucht die Maschine wahrscheinlich weniger ausführbare Prozesse, schnelleren Code oder mehr CPU-Kapazität.

3.2 Speicher und Paging (sar -r und sar -W)

Speicherstatistiken zeigen sowohl den Verbrauch als auch, ob das System auf Swapping oder Paging zurückgreift.

Speicherauslastung (sar -r):

sar -r 1 5

Konzentrieren Sie sich auf kbavail (verfügbarer Speicher). Wenn kbmemfree niedrig ist, aber kbcached und kbbuffers hoch sind, wird der Speicher vom Kernel-Caching-Mechanismus effizient genutzt.

Auslagerungsaktivität (sar -W):

sar -W 1 5

Achten Sie auf pswpin/s (eingelagerte Seiten) und pswpout/s (ausgelagerte Seiten). Jegliche signifikanten Nicht-Null-Werte hier deuten darauf hin, dass das System aggressiv auslagert, was auf Speicherdruck hindeutet (ein starker Engpass).

Die Linux-Speicherausgabe kann alarmierend aussehen, bis Sie sich daran erinnern, dass Cache kein verschwendeter Speicher ist. Ein Server mit sehr wenig kbmemfree kann immer noch gesund sein, wenn kbavail komfortabel ist und die Auslagerungsaktivität ruhig ist. Das gefährliche Muster ist anders: Der verfügbare Speicher sinkt, Ein- und Auslagerungsaktivität treten auf, und die Anwendungslatenz steigt. Das sagt Ihnen, dass Prozesse auf Speicher zugreifen, der nicht mehr in den RAM passt.

Für einen Webserver könnte das nach einem Deployment passieren, das versehentlich die Worker-Anzahl verdoppelt. Für einen Batch-Host könnte es passieren, wenn sich zwei große Jobs überschneiden. sar wird Ihnen nicht sagen, welcher Prozess es verursacht hat, aber es gibt Ihnen den Zeitstrahl. Kombinieren Sie es mit ps, top, Dienstprotokollen oder cgroup-Metriken, um den Verursacher zu identifizieren.

3.3 Festplatten-I/O-Aktivität (sar -d)

Die Überwachung der Festplattenaktivität ist entscheidend für Datenbankserver oder stark ausgelastete Speichersysteme.

sar -d 3 5

Diese Ausgabe erfordert die Identifizierung der spezifischen Geräte (z. B. sda, vda). Zu den wichtigsten Metriken gehören:

• tps: Übertragungen pro Sekunde (ein hoher Wert deutet auf hohe I/O-Anforderungen hin).
• rd_sec/s & wr_sec/s: Menge der pro Sekunde gelesenen/geschriebenen Daten.
• %util: Prozentsatz der Zeit, in der das Gerät mit der Bearbeitung von Anforderungen beschäftigt war. Wenn %util bei einem herkömmlichen Blockgerät nahe 100% bleibt, ist der Speicher möglicherweise gesättigt.

Bei modernen SSDs und virtuellen Festplatten verdient %util Kontext. Einige Geräte verarbeiten paralleles I/O gut, und Cloud-Volumes können durch bereitgestellte IOPS, Durchsatz oder Burst-Guthaben begrenzt sein. Behandeln Sie %util als Aufforderung, genauer hinzusehen, nicht als vollständige Diagnose. Bestätigen Sie mit iostat -xd, Anwendungslatenz und plattformbezogenen Speichermetriken, wenn Sie auf AWS, Azure, GCP oder einer anderen virtualisierten Umgebung sind.

Ein praktischer Arbeitsablauf ist:

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

Verwenden Sie sar, um die schlechte Stunde zu finden, und dann iostat während eines Live-Wiederauftretens, um die Gerätelatenz zu überprüfen.

3.4 Netzwerkstatistiken (sar -n)

sar kann Aktivitäten auf verschiedenen Netzwerkebenen melden. Die häufigste Überprüfung ist die Schnittstellenaktivität (DEV).

sar -n DEV 5 1

Dieser Befehl zeigt Metriken wie rxpk/s (empfangene Pakete pro Sekunde) und txkB/s (gesendete Kilobyte pro Sekunde) für jede Netzwerkschnittstelle. Verwenden Sie dies, um Schnittstellen zu identifizieren, die stark belastet sind oder potenzielle Fehler aufweisen.

Für Fehlerzähler fügen Sie EDEV hinzu:

sar -n EDEV 5 3

Dies kann Empfangsfehler, Übertragungsfehler, Verluste und Kollisionen anzeigen, sofern vom Treiber unterstützt. Verluste sind besonders nützlich, wenn sich ein Dienst über zeitweilige Timeouts beschwert, aber CPU und Festplatte normal aussehen. Wenn die Verluste während Verkehrsspitzen ansteigen, müssen Sie möglicherweise NIC-Warteschlangen, Kernel-Netzwerkeinstellungen, Container-Netzwerke oder den Load-Balancer-Pfad überprüfen.

Für TCP-Verhalten versuchen Sie:

sar -n TCP,ETCP 5 3

Erneute Übertragungen, Rücksetzungen und fehlgeschlagene Verbindungsversuche können einen vagen Bericht "die Seite ist langsam" in ein spezifischeres Netzwerk- oder Upstream-Problem verwandeln.

4. Historische Analyse und Erstellung von Baselines

Die wahre Stärke von sysstat liegt in seiner Fähigkeit, Systemaktivitäten über längere Zeiträume zu analysieren, was für die Erstellung von Leistungsbaselines (was ist normal für Ihr System) unerlässlich ist.

4.1 Analyse vergangener Tage

Um Daten eines vergangenen Tages anzuzeigen, verwenden Sie das Flag -f, um den Pfad zur täglichen saXX-Datei anzugeben.

Beispiel: Um CPU-Statistiken vom 10. Tag des aktuellen Monats anzuzeigen:

sar -u -f /var/log/sa/sa10

Um Statistiken innerhalb eines bestimmten Zeitfensters an diesem Tag zu überprüfen, fügen Sie die Flags -s (Startzeit) und -e (Endzeit) hinzu (im 24-Stunden-Format).

# Netzwerkstatistiken von 14:00 bis 16:30 am 10. anzeigen
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 Erstellen von Baselines

1. Daten sammeln: Führen Sie sysstat durch normale Hoch- und Niedriglastphasen.
2. Normen identifizieren: Analysieren Sie historische Daten (sar -f), um die durchschnittliche CPU-Auslastung (%user, %system), die Spitzen-I/O-Latenz (%util) und die durchschnittliche Speichernutzung zu bestimmen.
3. Schwellenwerte definieren: Behandeln Sie anhaltende Abweichungen von Ihrer eigenen Baseline als Auslöser für Untersuchungen. Ein vielbeschäftigter Datenbank-Host und ein ruhiger Jump-Host sollten nicht dieselben Schwellenwerte teilen.

Baselines sind nützlicher, wenn sie an reale Geschäftsrhythmen gebunden sind. Ein Montagmorgen-Batch-Import, ein nächtliches Backup und ein Produktstart erzeugen alle unterschiedliche "normale" Formen. Machen Sie sich Notizen, wenn Sie Untersuchungen durchführen: "Backup begann um 01:00", "neues Release um 14:30", "Marketing-E-Mail um 09:05". Diese Notizen machen die historische sar-Ausgabe später viel leichter interpretierbar.

5. Unterstützende Sysstat-Tools

Während sar das übergreifende Werkzeug ist, enthält die sysstat-Suite spezialisierte Dienstprogramme, die fokussierte, detaillierte Berichte bieten.

5.1 iostat (Eingabe-/Ausgabestatistiken)

iostat bietet detaillierte Metriken, die sich speziell auf die Geräteauslastung konzentrieren, besonders nützlich bei der Diagnose von Speicherengpässen.

# Festplattenstatistiken alle 2 Sekunden, 4 Mal, einschließlich erweiterter Statistiken (x)
iostat -xd 2 4

Wichtige iostat-Metriken:

• %util: Der Prozentsatz der CPU-Zeit, während der I/O-Anforderungen an das Gerät gesendet wurden (entscheidender Indikator für Sättigung).
• await: Die durchschnittliche Wartezeit (in Millisekunden) für I/O-Anforderungen, die an das Gerät gesendet wurden. Hohe await deutet auf langsame Speicherreaktionsfähigkeit hin.

Wenn await springt, aber der Durchsatz nicht hoch ist, suchen Sie nach kleinen zufälligen I/Os, Dateisystemproblemen, lauten Nachbarn in der virtuellen Infrastruktur oder einer Anwendung, die viele synchrone Schreibvorgänge durchführt. Wenn der Durchsatz hoch ist und die Latenz damit steigt, ist das Gerät möglicherweise einfach an seiner praktischen Grenze.

5.2 mpstat (Mehrprozessor-Statistiken)

Wenn Sie CPU-Planungsprobleme oder eine ungleichmäßige Arbeitslastverteilung über die Kerne vermuten, liefert mpstat prozessorspezifische Nutzungsstatistiken, etwas, das sar -u aggregiert.

# Nutzung für alle CPUs (A) alle 2 Sekunden anzeigen
mpstat -P ALL 2 1

Dies ist unschätzbar für die Identifizierung von Single-Threaded-Anwendungen, die einen einzelnen Kern sättigen, während andere im Leerlauf sind, oder für die Diagnose der Hyperthreading-Effizienz.

5.3 sadf (Exportieren von Sysstat-Daten)

sadf liest dieselben gesammelten Daten wie sar, kann sie aber in Formaten ausgeben, die für Skripte und Dashboards leichter zu verarbeiten sind.

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

Die -d-Ausgabe ist nützlich für die Verarbeitung von getrenntem Text. Die -j-Ausgabe ist nützlich, wenn Sie JSON möchten. Dies ist praktisch, wenn Sie Beweise an eine Incident-Überprüfung anhängen oder zwei Hosts vergleichen müssen, ohne manuell Terminalausgaben zu kopieren.

6. Ein praktischer Incident-Walkthrough

Stellen Sie sich einen API-Server vor, der um 10:15 Uhr anfing, Timeouts zu geben. Die Anwendungsprotokolle zeigen, dass sich Anfragen stapeln, aber sie erklären nicht, warum. Beginnen Sie mit der historischen CPU-Ansicht:

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Wenn %user hoch und %idle niedrig ist, ist die App möglicherweise CPU-gebunden. Überprüfen Sie die Nutzung pro Kern:

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Wenn ein Kern ausgelastet ist, während andere ruhig sind, vermuten Sie einen Single-Threaded-Worker, einen Hot Lock oder eine ungleichmäßige Prozessverteilung. Wenn alle Kerne beschäftigt sind, sehen Sie sich die Anforderungsrate, kürzliche Deployments und teure Codepfade an.

Wenn die CPU größtenteils im Leerlauf zu sein scheint, aber %iowait ansteigt, wechseln Sie zur Festplatte:

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Eine hohe Geräteauslastung oder eine steigende Warteschlangentiefe um dieselbe Zeit deutet auf Speicher hin. Bei einem datenbankgestützten Dienst ist der nächste Halt die Datenbankprotokolle und langsame Abfragedaten. Bei einem dateibedienenden Host überprüfen Sie, ob ein Backup, ein Komprimierungsjob oder eine Log-Rotation zur gleichen Zeit lief.

Wenn CPU und Festplatte in Ordnung aussehen, überprüfen Sie Speicher und Netzwerk:

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Der Punkt ist nicht, jedes Mal jeden Befehl auszuführen. Der Punkt ist, den Beweisen zu folgen. sar gibt Ihnen einen Zeitstrahl über Ressourcenklassen hinweg, was normalerweise das ist, was Sie brauchen, um nicht mehr dem lautesten Symptom hinterherzujagen.

Eine einfache Betriebsgewohnheit

Der beste Weg, sysstat zu lernen, ist, es zu verwenden, bevor etwas kaputt geht. Überprüfen Sie einen gesunden Server während des normalen Verkehrs. Überprüfen Sie ihn während Backups. Überprüfen Sie ihn nach einem Deployment. Speichern Sie ein paar Befehlsmuster, die zu Ihrer Umgebung passen.

Wenn ein Vorfall eintritt, werden Sie bereits wissen, wie normal aussieht. Das ist der wahre Wert des Toolkits. sar, iostat, mpstat und sadf diagnostizieren nicht magisch die Anwendung für Sie, aber sie halten das Gespräch auf Beweise gestützt: wann das Problem begann, welche Ressource sich geändert hat und ob der Host tatsächlich unter Druck stand.