Fehlerbehebung bei hoher Datenträger-I/O-Latenz: Eine Schritt-für-Schritt-Anleitung für Linux

Hohe Datenträger-I/O-Latenz hat ein sehr spezifisches Gefühl. SSH verbindet sich immer noch, die CPU ist nicht ausgelastet, aber jeder Befehl, der Dateien berührt, hängt einen Moment. Eine Web-App pausiert, während Sitzungen geschrieben werden. Eine Datenbankabfrage, die normalerweise schnell zurückkommt, beginnt auf Speicher zu warten. Die Maschine sieht lebendig aus, aber es fühlt sich an, als würde sie durch Schlamm waten.

Der Trick ist, Raten zu vermeiden. „Die Festplatte ist langsam“ kann einen gesättigten Blockgerät, Swap-Thrashing, ein defektes Laufwerk, einen lauten Backup-Job, ein überlastetes Netzwerkvolume oder eine Datenbank bedeuten, die zufällige Lesevorgänge durchführt, weil ein Index fehlt. Das gleiche Symptom kann von sehr unterschiedlichen Ursachen herrühren.

Grundlegendes zu Datenträger-I/O-Metriken

Bevor Sie mit der Fehlerbehebung beginnen, ist es wichtig, die wichtigsten Metriken zu verstehen, die auf ein I/O-Problem hinweisen. Hohe Latenz ist das primäre Symptom, aber wir benötigen unterstützende Datenpunkte, um den Schweregrad und die Quelle des Problems zu bestätigen.

Schlüsselindikatoren für I/O-Engpässe

Hohe Latenz (await): Die durchschnittliche Zeit in Millisekunden, die I/O-Anfragen benötigen, um abgeschlossen zu werden. Dies umfasst die Wartezeit in der Warteschlange und die Bearbeitungszeit. Was als „hoch“ gilt, hängt vom Speicher und der Arbeitslast ab; vergleichen Sie es nach Möglichkeit mit der normalen Baseline des Systems.
Hohe Auslastung (%util): Wenn diese Metrik sich 100% nähert, ist das Gerät gesättigt und kann keine weiteren Anfragen effizient bearbeiten.
Hohe Warteschlangenlänge (avgqu-sz): Eine große durchschnittliche Warteschlangengröße bedeutet, dass viele Prozesse darauf warten, dass die Festplatte frei wird.

Schritt 1: Erste Systemzustandsprüfung mit `iostat`

Das Dienstprogramm iostat (Teil des Pakets sysstat) ist der Eckpfeiler für die Überwachung der Geräteauslastung und Leistungsstatistiken. Es liefert historische und aktuelle Daten zur CPU- und Geräte-I/O.

Um eine laufende Aufzeichnung der I/O-Leistung zu erhalten, führen Sie iostat mit einem Intervall aus (z. B. alle 2 Sekunden):

sudo iostat -dxm 2

Analyse der `iostat -dxm`-Ausgabe

Konzentrieren Sie sich speziell auf die Spalten der Gerätestatistiken (x-Flag):

Spalte	Beschreibung	Auswirkung eines hohen Werts
r/s, w/s	Lese-/Schreibvorgänge pro Sekunde (IOPS)	Hohe Werte deuten auf eine hohe Durchsatzanforderung hin.
rkB/s, wkB/s	Pro Sekunde gelesene/geschriebene Kilobyte	Misst das Durchsatzvolumen.
await	Durchschnittliche Wartezeit (ms) für I/O-Anfragen (Servicezeit + Wartezeit)	Primärer Indikator für hohe Latenz.
%util	Prozentsatz der Zeit, in der das Gerät mit der Bearbeitung von Anfragen beschäftigt war	Nahe 100% deutet auf Sättigung hin.

Beispielszenario: Wenn /dev/sda eine await-Zeit von 150ms und %util von 98% anzeigt, haben Sie einen schwerwiegenden I/O-Engpass auf dieser Festplatte bestätigt.

Tipp: Verwenden Sie das Flag -x für erweiterte Statistiken und -m für die Angabe in Megabyte, was oft klarer ist als Kilobyte (-k).

Schritt 2: Identifizieren des verantwortlichen Prozesses mit `iotop`

Sobald iostat eine hohe Latenz auf einem bestimmten Gerät (z. B. /dev/sda) bestätigt hat, besteht der nächste entscheidende Schritt darin, zu bestimmen, welcher Prozess diese Last erzeugt. Das Dienstprogramm iotop, das die Funktionalität des Befehls top nachahmt, sich aber auf die I/O-Aktivität konzentriert, ist hier unerlässlich.

Wenn iotop nicht installiert ist, installieren Sie es zuerst:

# Debian/Ubuntu
sudo apt update && sudo apt install iotop

# RHEL/CentOS/Fedora
sudo yum install iotop  # oder dnf install iotop

Führen Sie iotop mit Root-Rechten aus und zeigen Sie nur Prozesse an, die aktiv I/O durchführen:

sudo iotop -oP

-o: Nur Prozesse anzeigen, die aktiv I/O durchführen.
-P: Prozesse anzeigen, nicht einzelne Threads.

Untersuchen Sie die Ausgabe und achten Sie auf die Spalten IO_READ und IO_WRITE. Die oben aufgeführten Prozesse verbrauchen die meiste Festplattenbandbreite. Häufige Übeltäter sind Datenbankserver (MySQL, PostgreSQL), Backup-Dienstprogramme, Log-Rotationsskripte oder Systeme, die aggressiv in den Swap-Bereich schreiben.

Interpretieren der `iotop`-Ausgabe

iotop zeigt die gesamte Festplattennutzung für jeden Prozess an. Wenn Sie sehen, dass eine einzelne Anwendung die Festplattenauslastung dominiert (z. B. ein Backup-Skript, das mit 50 MB/s läuft, während die Latenz in die Höhe schießt), haben Sie die unmittelbare Ursache gefunden.

Schritt 3: Tiefergehende Analyse mit `pidstat`

Während iotop die aggregierte I/O pro Prozess anzeigt, kann pidstat detaillierte historische Zusammenhänge zu I/O-Operationen liefern, die von bestimmten PIDs initiiert wurden. Dies ist nützlich für langlaufende oder intermittierende Probleme.

Um I/O-Statistiken (Lesen und Schreiben von Blöcken) für alle Prozesse alle 5 Sekunden für 5 Iterationen zu überwachen:

sudo pidstat -d 5 5

Zu den wichtigsten Metriken in der -d-Ausgabe gehören:

kB_rd/s: Datenmenge, die pro Sekunde von der Festplatte durch die Aufgabe gelesen wird.
kB_wr/s: Datenmenge, die pro Sekunde von der Aufgabe auf die Festplatte geschrieben wird.
kB_ccwr/s: Datenmenge, die in den Swap-Bereich geschrieben wird (c=abgebrochene/committete Schreibvorgänge).

Wenn Lese- und Schreibvorgänge für denselben Prozess jedes Mal ansteigen, wenn Benutzer Pausen melden, haben Sie einen nützlichen Hinweis. pidstat ist besonders hilfreich, wenn iotop einen kurzen Spike anzeigt und dann verschwindet, bevor Sie ihn lesen können.

Schritt 4: Diagnose von Speicher-Thrashing (Swap-Nutzung)

Hohe Swap-Aktivität äußert sich oft als hohe Datenträger-I/O-Latenz, da das System gezwungen ist, die langsame physische Festplatte als virtuellen RAM zu verwenden. Verwenden Sie den Befehl free, um den Speicherdruck zu überprüfen:

free -h

Wenn der verwendete Speicher nahe am gesamten Speicher liegt und der verwendete Swap-Wert schnell ansteigt, ist das System speicherhungrig, und die I/O-Latenz ist ein sekundäres Symptom des Swappings.

Behebung von Thrashing:

Identifizieren Sie speicherhungrige Prozesse mit top oder htop.
Erhöhen Sie nach Möglichkeit den Systemspeicher.
Optimieren Sie Anwendungen, um weniger Speicher zu verbrauchen.

Überprüfen Sie auch vmstat, während das Problem auftritt:

vmstat 1

Die Spalten si und so zeigen Swap-In- und Swap-Out-Aktivitäten. Gelegentliche Werte ungleich Null sind nicht automatisch eine Krise. Anhaltende Aktivität bei gleichzeitig langsamen System ist ein stärkeres Signal. Die CPU-Spalte wa ist ebenfalls nützlich: Hohe I/O-Wartezeit bedeutet, dass Aufgaben Zeit damit verbringen, auf den Speicher blockiert zu sein, anstatt auf der CPU zu laufen.

Schritt 5: Gerät dem Dateisystem zuordnen

iostat meldet Blockgeräte: sda, nvme0n1, dm-0, md0 usw. Ihre Anwendungsprotokolle erwähnen normalerweise Pfade: /var/lib/mysql, /var/log, /home, /data. Bevor Sie die falsche Festplatte beschuldigen, ordnen Sie den Pfad dem Gerät zu.

df -hT /var/lib/mysql
findmnt /var/lib/mysql
lsblk -f

Dies ist auf Hosts mit LVM, Software-RAID, Cloud-Volumes oder separaten Mountpunkten wichtig. Möglicherweise sehen Sie eine hohe Latenz auf dm-0, aber das eigentliche zugrunde liegende Gerät könnte ein EBS-Volume, ein mdraid-Array oder ein verschlüsseltes Mapper-Gerät sein. Wenn sich das ausgelastete Dateisystem auf einem Netzwerkspeicher befindet, erzählen lokale Festplatten-Tools nur einen Teil der Geschichte. Sie müssen auch NFS, iSCSI, Cloud-Volume-Metriken oder das Speichergerät überprüfen.

Schritt 6: Suche nach Kernel- und Hardware-Hinweisen

Wenn die Latenz hoch ist, der Durchsatz jedoch nicht, überprüfen Sie auf Speicherfehler. Eine defekte Festplatte oder ein rückfallanfälliger Controller können das System selbst bei bescheidener I/O zum Kriechen bringen.

dmesg -T | egrep -i 'error|reset|timeout|nvme|scsi|blk_update|i/o error'
journalctl -k --since "30 minutes ago"

Bei physischen Festplatten können SMART-Daten nützlich sein:

sudo smartctl -a /dev/sda

Für NVMe-Geräte:

sudo nvme smart-log /dev/nvme0

Überinterpretieren Sie nicht ein einzelnes SMART-Feld isoliert. Verschiedene Hersteller legen unterschiedliche Zähler offen. Aber neu zugeordnete Sektoren, Medienfehler, wiederholte Befehlszeitüberschreitungen oder Kernel-I/O-Fehler verdienen sofortige Aufmerksamkeit. Wenn die Festplatte eine Produktionsdatenbank unterstützt, hören Sie auf, dies als Optimierungsübung zu behandeln, und bewegen Sie sich in Richtung Redundanz, Failover oder Austausch.

Schritt 7: Bandbreitenprobleme von Latenzproblemen trennen

Zwei Vorfälle können beide „langsame Festplatte“ zeigen, aber unterschiedliche Korrekturen erfordern.

Ein sequenzielles Backup könnte hohe wkB/s und hohe %util verursachen. Dies ist ein Bandbreitenproblem. Die Drosselung des Backups, die Verschiebung außerhalb der Spitzenzeiten, die Verwendung inkrementeller Backups oder das Schreiben auf ein anderes Volume können helfen.

Eine Datenbank mit fehlenden Indizes könnte einen bescheidenen Durchsatz, aber schmerzhafte await, viele kleine Lesevorgänge und für den Benutzer sichtbare Abfrageverzögerungen aufweisen. Dies ist oft ein Problem mit zufälliger I/O und Abfrageform. Mehr Bandbreite kann weniger helfen als das Hinzufügen des richtigen Index oder die Reduzierung des Arbeitssatzes.

Verwenden Sie diese schnelle Einordnung:

Hohe rkB/s oder wkB/s, hohe %util, offensichtlicher großer Job: Suchen Sie nach Massen-Lese-/Schreibvorgängen.
Hohe r/s oder w/s, hohe await, geringerer Durchsatz: Suchen Sie nach vielen kleinen zufälligen Operationen.
Hohe Swap-Aktivität, hohe wa, wenig freier Speicher: Behandeln Sie Speicherdruck als Grundursache.
Hohe Latenz mit Kernel-Fehlern: Behandeln Sie die Speichergesundheit als Grundursache.

Schritt 8: Überprüfung des Anwendungskontexts

Systemtools sagen Ihnen, wer den Speicher berührt. Sie sagen Ihnen nicht immer, warum.

Bei Datenbanken überprüfen Sie die langsamen Abfrageprotokolle und Puffer-/Cache-Metriken. Ein MySQL-Prozess an der Spitze von iotop kann während eines Backups normal, während des Spitzenverkehrs schlecht oder nach einem Neustart erwartet sein, während der Buffer Pool kalt ist. PostgreSQL führt möglicherweise Autovacuum, Checkpoint-Schreibvorgänge oder eine Abfrage durch, die auf die Festplatte ausgelagert wird. MongoDB komprimiert möglicherweise, erstellt Indizes oder liest einen Arbeitssatz, der nicht mehr in den RAM passt.

Bei Webservern und App-Workern suchen Sie nach Protokollstürmen. Ein aktiviertes Debug-Protokoll kann stetige synchrone Schreibvorgänge erzeugen. Eine fehlschlagende Abhängigkeit kann auch wiederholte Fehlerprotokolle erzeugen, die dann Festplattendruck verursachen, was den ursprünglichen Vorfall verschlimmert.

Bei Containern denken Sie daran, dass der laute Prozess unter containerd, dockerd oder einem Overlay-Dateisystem erscheinen kann. Verwenden Sie auch Tools auf Containerebene:

docker stats
docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'

Auf Kubernetes-Knoten vergleichen Sie die I/O auf Host-Ebene mit der Pod-Platzierung. Ein einzelner Pod, der stark in ein emptyDir, hostPath oder lokales persistentes Volume schreibt, kann nicht zusammenhängende Pods auf demselben Knoten ungesund erscheinen lassen.

Häufige Ursachen und Abhilfestrategien

Sobald die Quelle identifiziert ist, wenden Sie die entsprechende Korrektur an:

1. Backups oder Wartungsjobs

Symptom: Hohe I/O-Auslastung zeitgleich mit geplanten Jobs (z. B. Cron-Jobs). Abhilfe: Planen Sie große I/O-Jobs neu, drosseln Sie sie, wenn das Dienstprogramm dies unterstützt, oder verschieben Sie die temporäre Ausgabe auf ein anderes Volume. Beispielsweise können rsync --bwlimit, ionice und datenbankeigene Backup-Drosseln die Auswirkung reduzieren.

2. Ineffiziente Datenbankabfragen

Symptom: Datenbankprozesse (z. B. mysqld) sind die Hauptverbraucher in iotop. Abhilfe: Optimieren Sie schlecht indizierte Abfragen, die vollständige Tabellenscans erzwingen, was zu massiven zufälligen Lesevorgängen führt.

3. Übermäßige Protokollierung

Symptom: Anwendungs- oder Systemprotokollierungsprozesse schreiben große Datenmengen. Abhilfe: Überprüfen Sie die Protokollierungsstufen der Anwendung. Erwägen Sie die Pufferung von Protokollen oder die Verwendung einer Remote-Protokollierungslösung (wie Syslog oder ELK Stack), um lokale Festplattenschreibvorgänge zu reduzieren.

4. Festplattenfehler oder Fehlkonfiguration

Symptom: Extrem hohe await-Zeiten, die nicht mit hohem Durchsatz korrelieren, oder seltsame Lese-/Schreibmuster. Dies kann auf defekte Hardware oder eine falsche RAID-Konfiguration hinweisen. Abhilfe: Überprüfen Sie die SMART-Daten (smartctl) auf die Festplattengesundheit. Wenn RAID verwendet wird, überprüfen Sie den Status des Arrays.

5. Dateisystem- oder Mount-Optionen

Symptom: Latenz tritt bei Metadaten-intensiven Arbeitslasten auf: Erstellen vieler kleiner Dateien, Löschen von Verzeichnissen, Rotieren von Protokollen oder Entpacken von Archiven.

Abhilfe: Überprüfen Sie den Dateisystemtyp, die Mount-Optionen, die Inode-Nutzung und das Journal-Verhalten. Ein volles Dateisystem, erschöpfte Inodes oder ein fast volles Thin-Provisioned-Volume können von der Anwendungsseite wie ein I/O-Latenzproblem aussehen.

df -h
df -ih
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Wenn die Inode-Nutzung bei 100% liegt, hilft das Löschen einer riesigen Datei nicht. Sie müssen viele kleine Dateien entfernen oder diese Arbeitslast auf ein Dateisystemlayout verschieben, das dafür ausgelegt ist.

Best Practices für proaktive Überwachung

Die Verhinderung von I/O-Engpässen ist besser als deren reaktive Behebung. Implementieren Sie eine kontinuierliche Überwachung:

Alarme einrichten: Konfigurieren Sie Überwachungstools so, dass sie bei anhaltenden Änderungen der Festplattenlatenz, Warteschlangentiefe, I/O-Wartezeit, Dateisystemfüllung und Fehlerzählern alarmieren. Verwenden Sie Schwellenwerte, die Ihrer Speicherklasse und Arbeitslast entsprechen, anstatt eine universelle Zahl zu kopieren.
Leistungs-Baseline: Wissen Sie, wie „normale“ I/O-Latenz für Ihre spezifische Arbeitslast aussieht. Dies macht Anomalien leichter erkennbar.
Arbeitslasttyp verstehen: Zufällige I/O-Muster (häufig in Datenbanken) verursachen eine viel höhere Latenz als sequenzielle I/O (häufig bei Medien-Streaming oder großen Dateilesevorgängen).

Die besten Untersuchungen zur Festplattenlatenz grenzen die Frage immer weiter ein: welches Gerät, welches Dateisystem, welcher Prozess, welche Arbeitslast und welche kürzliche Änderung? Sobald Sie diese Kette haben, ist die Korrektur normalerweise klarer. Sie hören auf, zufällig Kernel-Einstellungen zu optimieren, und beginnen, den Backup-Zeitplan zu ändern, Speicher hinzuzufügen, Speicher zu reparieren, eine Abfrage zu korrigieren oder eine laute Arbeitslast von einer gemeinsam genutzten Festplatte wegzubewegen.