Fehlerbehebung bei Linux-Ressourcenerschöpfung: CPU, Arbeitsspeicher und Festplattenspeicher

Wenn einem Linux-Server CPU, Arbeitsspeicher oder Festplattenspeicher ausgehen, ist das erste Symptom meist vage: Die Website ist langsam, SSH hängt nach dem Login, Bereitstellungen schlagen fehl oder ein Dienst startet immer wieder neu. Der schnellste Weg durch den Vorfall besteht darin, zu identifizieren, welche Ressource erschöpft ist, und dann den dahinterstehenden Prozess oder das Dateisystem zu finden.

Führen Sie zuerst die risikoärmsten Prüfungen durch. Schreibgeschützte Befehle wie top, free, df, du, vmstat und journalctl geben Ihnen ein Bild, ohne die Maschine zu verändern. Das Beenden von Prozessen und Löschen von Dateien kann notwendig sein, ist aber keine Diagnose.

Identifizierung des Übeltäters: Überwachung von Systemressourcen

Bevor Sie ein Problem mit Ressourcenerschöpfung beheben können, müssen Sie ermitteln, welche Ressource übermäßig genutzt wird und welcher Prozess dafür verantwortlich ist. Linux bietet eine Vielzahl von Befehlszeilenwerkzeugen für diesen Zweck.

Überwachung der CPU-Auslastung

Eine hohe CPU-Auslastung kann Ihr System langsam und träge erscheinen lassen. Sie wird oft durch einen außer Kontrolle geratenen Prozess, eine anspruchsvolle Anwendung oder ein ineffizientes Skript verursacht.

top: Dies ist ein unverzichtbarer Echtzeit-Systemmonitor. Er zeigt eine dynamische Liste von Prozessen an, standardmäßig sortiert nach CPU-Auslastung. Sie können die gesamte CPU-Auslastung, Speichernutzung und Details zu einzelnen Prozessen sehen.
```
top
```
Drücken Sie innerhalb von top die Taste 1, um die Auslastung einzelner CPU-Kerne zu sehen. Drücken Sie P, um nach CPU-Auslastung zu sortieren. Achten Sie auf Prozesse, die dauerhaft einen hohen CPU-Prozentsatz verbrauchen.
htop: Eine erweiterte, interaktive Version von top. Sie wird oft wegen ihrer Benutzerfreundlichkeit, farbigen Ausgabe und einfacheren Navigation bevorzugt.
```
htop
```
Ähnlich wie top ermöglicht htop das Sortieren nach CPU-Auslastung und bietet detaillierte Prozessinformationen.
mpstat: Teil des sysstat-Pakets, liefert mpstat detaillierte CPU-Statistiken, einschließlich der Nutzung pro Prozessor, Interrupt-Zähler und Kontextwechsel.
```
mpstat -P ALL 1
```
Dieser Befehl zeigt jede Sekunde CPU-Statistiken für alle Kerne an.

Überprüfen Sie auch die Lastverteilung im Vergleich zur CPU-Anzahl:

uptime
nproc

Eine Lastverteilung von 8 bedeutet auf einer 2-Kern-VM etwas ganz anderes als auf einem 32-Kern-Host. Die Last umfasst auch Aufgaben, die auf nicht unterbrechbare E/A warten, daher kann eine hohe Lastverteilung bei geringer CPU-Auslastung tatsächlich auf Festplatten- oder Netzwerkspeicher hindeuten.

Überwachung der Speichernutzung

Wenn einem System der verfügbare RAM und Swap-Speicher ausgehen, beginnt es, Festplattenspeicher als virtuellen Speicher zu nutzen, was erheblich langsamer ist und zu schwerwiegenden Leistungseinbußen führt.

free -h: Zeigt die Gesamtmenge an freiem und genutztem physischem und Swap-Speicher im System sowie die vom Kernel verwendeten Puffer und Caches an. Das Flag -h macht die Ausgabe menschenlesbar (z. B. MB, GB).
```
free -h
```
Achten Sie auf den available-Speicher und den genutzten Swap-Speicher. Eine hohe Swap-Nutzung deutet auf unzureichenden RAM hin.
top / htop: Sowohl top als auch htop zeigen die Speichernutzung pro Prozess. Achten Sie auf Prozesse mit einem hohen %MEM-Wert.
vmstat: Meldet Statistiken zum virtuellen Speicher. Es kann Informationen über Prozesse, Speicher, Paging, Block-E/A, Traps und CPU-Aktivität anzeigen.
```
vmstat 5
```
Dieser Befehl meldet alle 5 Sekunden Statistiken. Achten Sie auf die Spalten si (Swap-In) und so (Swap-Out); hohe Werte deuten auf erheblichen Speicher-Swapping hin.

Überprüfen Sie bei möglichen OOM-Kills das Kernel-Log:

dmesg -T | grep -i 'killed process'
journalctl -k --since "1 hour ago" | grep -i oom

Ein OOM-Kill ändert den Vorfall. Die unmittelbare Frage ist, welcher Prozess getötet wurde, warum er den verfügbaren Speicher überschritten hat und ob systemd oder ein Orchestrator ihn neu gestartet hat.

Überwachung des Festplattenspeichers

Eine volle Festplattenpartition kann verhindern, dass Anwendungen Daten schreiben, Fehler verursachen und sogar verhindern, dass das System bootet.

df -h: Meldet die Festplattennutzung des Dateisystems. Das Flag -h macht die Ausgabe menschenlesbar.
```
df -h
```
Dieser Befehl listet alle eingehängten Dateisysteme auf und zeigt ihre Gesamtgröße, genutzten Speicher, verfügbaren Speicher und Einhängepunkt an. Achten Sie auf Partitionen, die zu 100% oder nahezu voll sind.
du -sh <verzeichnis>: Schätzt die Dateispeichernutzung für ein bestimmtes Verzeichnis. Das Flag -s fasst zusammen, und -h macht es menschenlesbar.
```
du -sh /var/log/*
```
Verwenden Sie dies, um herauszufinden, welche Unterverzeichnisse den meisten Festplattenspeicher verbrauchen.

Überprüfen Sie auch die Inode-Nutzung:

df -ih

Ein Dateisystem kann freie Gigabytes haben und dennoch keine Dateien erstellen können, wenn ihm die Inodes ausgegangen sind. Dies passiert bei Millionen von winzigen Dateien: Cache-Einträge, Mail-Warteschlangen, Sitzungsdateien, Build-Artefakte oder schlecht rotierte Logs.

Behebung von Problemen mit Ressourcenerschöpfung

Sobald Sie die problematische Ressource und den störenden Prozess identifiziert haben, können Sie Maßnahmen zur Behebung des Problems ergreifen.

Behebung hoher CPU-Auslastung

Identifizieren Sie den Prozess: Verwenden Sie top oder htop, um die Prozess-ID (PID) zu finden, die viel CPU verbraucht.
Untersuchen Sie den Prozess: Stellen Sie fest, um was für einen Prozess es sich handelt. Ist es eine Benutzeranwendung, ein Systemdienst oder etwas Unerwartetes?
- Legitime hohe Auslastung: Wenn eine legitime Anwendung viel CPU verbraucht (z. B. Kompilieren von Software, Videokodierung), müssen Sie möglicherweise warten, bis sie fertig ist, sie für verkehrsärmere Zeiten planen oder Ihre Hardware aufrüsten.
- Außer Kontrolle geratener Prozess: Wenn ein Prozess in einer Schleife steckt oder unbeabsichtigt übermäßig CPU verbraucht, können Sie versuchen, ihn neu zu starten. Wenn das nicht funktioniert, müssen Sie ihn möglicherweise beenden.
Beenden Sie den Prozess (mit Vorsicht verwenden!): Sie können den Befehl kill verwenden, um Signale an Prozesse zu senden. Die häufigsten Signale sind:
- SIGTERM (15): Fordert den Prozess höflich auf, sich zu beenden.
- SIGKILL (9): Beendet den Prozess sofort gewaltsam. Dies sollte das letzte Mittel sein, da es dem Prozess nicht erlaubt, sich zu bereinigen.
```
# Prozess mit PID 1234 höflich beenden
kill 1234

# Prozess mit PID 1234 gewaltsam beenden
kill -9 1234
```
Überprüfen Sie die Logs: Untersuchen Sie Systemlogs (z. B. /var/log/syslog, /var/log/messages, anwendungsspezifische Logs) auf Fehler im Zusammenhang mit dem problematischen Prozess.
Optimieren Sie Anwendungen/Skripte: Wenn die hohe CPU-Auslastung auf eine ineffiziente Anwendung oder ein ineffizientes Skript zurückzuführen ist, sollten Sie eine Optimierung des Codes oder der Konfiguration in Betracht ziehen.

Hohe CPU ist nicht immer schlecht. Ein Batch-Job, der für kurze Zeit alle Kerne nutzt, kann in Ordnung sein. Ein Single-Thread-Prozess, der bei 100% eines Kerns feststeckt, während sich Anfragen dahinter anstauen, ist etwas anderes. Achten Sie auf Dauer, Benutzerauswirkungen und ob der Prozess erwartungsgemäß ausgelastet sein sollte.

Wenn Sie vor dem Neustart eines Dienstes mehr Kontext benötigen, machen Sie eine Momentaufnahme:

ps -fp <pid>
sudo lsof -p <pid> | head
sudo strace -p <pid> -tt -T -f

Verwenden Sie strace vorsichtig auf Produktionssystemen. Es kann Overhead verursachen, aber eine kurze Stichprobe sagt Ihnen oft, ob der Prozess schleift, auf Dateien wartet, Netzwerkaufrufe fehlschlagen oder wiederholt dieselbe Ressource öffnet.

Behebung von Speicherlecks und -erschöpfung

Ein Speicherleck tritt auf, wenn ein Programm Speicher, den es nicht mehr benötigt, nicht freigibt und nach und nach den gesamten verfügbaren RAM verbraucht. Dies kann zu übermäßigem Swapping und Systemträgheit führen.

Identifizieren Sie den Prozess: Verwenden Sie top oder htop, um Prozesse mit hohem Speicherverbrauch (%MEM) oder Resident Set Size (RSS)-Werten zu finden, die im Laufe der Zeit stetig ansteigen.
Untersuchen Sie den Prozess: Bestimmen Sie die Art der Anwendung. Handelt es sich um eine bekannte Anwendung mit potenziellen Speicherproblemen oder um etwas Eigenes?
Starten Sie die Anwendung/den Dienst neu: Oft kann ein einfacher Neustart der Anwendung oder des Dienstes ein Speicherleck vorübergehend beheben, indem der angesammelte Speicher freigegeben wird.
```
# Beispiel: Neustart des Apache-Webservers
sudo systemctl restart apache2
```
Überprüfen Sie anwendungsspezifische Überwachung: Viele Anwendungen (z. B. Webserver, Datenbanken) haben eigene Überwachungstools oder Logs, die bei der Diagnose von Speicherproblemen helfen können.
Analysieren Sie Core Dumps: Bei kritischen Anwendungen müssen Sie möglicherweise Core Dumps aktivieren und Debugging-Tools (wie gdb) verwenden, um den Speicherzustand zu analysieren, wenn das Leck auftritt. Dies ist ein fortgeschrittener Schritt zur Fehlerbehebung.
Erhöhen Sie den Swap-Speicher (vorübergehende Maßnahme): Wenn Sie das Leck nicht sofort beheben können, können Sie den Swap-Speicher erhöhen, um mehr virtuellen Speicher bereitzustellen. Dies ist jedoch eine Problemumgehung, keine Lösung.
Hardware-Upgrade: Wenn Ihrem System für seine Arbeitslast ständig der Speicher ausgeht, müssen Sie möglicherweise mehr physischen RAM hinzufügen.

Eine bessere Speicheruntersuchung beobachtet Veränderungen im Laufe der Zeit. Ein einzelner top-Screenshot sagt nur, wer gerade groß ist. Ein Leck ist ein Trend.

while true; do
  date
  ps -eo pid,comm,rss,%mem --sort=-rss | head -15
  sleep 60
done

Wenn derselbe Prozess über mehrere Stichproben hinweg stetig ansteigt, ohne nach einem Rückgang des Datenverkehrs abzufallen, haben Sie ein stärkeres Leck-Signal. Wenn viele Prozesse während der Spitzenlast gemeinsam wachsen, übersteigt die Arbeitslast möglicherweise einfach die Kapazität oder die Parallelitätsgrenzen.

Überprüfen Sie bei systemd-Diensten, ob bereits Speichergrenzen vorhanden sind:

systemctl show <dienst> -p MemoryCurrent -p MemoryMax

Bei Containern kann free -h auf Hostebene in Ordnung aussehen, während ein Container seine eigene Grenze erreicht. Überprüfen Sie docker stats, kubectl top pod oder die Orchestrator-Ereignisse auf OOM-Kills.

Verwalten voller Festplattenpartitionen

Wenn eine Festplattenpartition voll wird, kann dies verschiedene Systemausfälle verursachen. In der Regel ist sofortiges Handeln erforderlich.

Identifizieren Sie die volle Partition: Verwenden Sie df -h, um die Partition(en) zu lokalisieren, die zu 100% voll sind.
Finden Sie große Dateien/Verzeichnisse: Verwenden Sie du -sh oder du -h --max-depth=1 <verzeichnis>, um im Verzeichnisbaum nach unten zu navigieren und herauszufinden, was den Speicherplatz verbraucht.
```
# Finden Sie die größten Verzeichnisse in der Root-Partition
sudo du -h --max-depth=1 / | sort -rh
```
Häufige Übeltäter sind Logdateien (/var/log), temporäre Dateien (/tmp), Paket-Caches und Benutzerdaten.
Bereinigen Sie Logdateien: Logdateien können sehr groß werden. Sie können alte Logs oft sicher löschen oder die Log-Rotation (logrotate) konfigurieren, um ihre Größe automatisch zu verwalten.
- Löschen alter Logs: Seien Sie vorsichtig und stellen Sie sicher, dass Sie keine aktuell aktiven Logs löschen. Sie können find verwenden, um Dateien zu löschen, die älter als eine bestimmte Anzahl von Tagen sind.
```
# Löschen Sie .log-Dateien, die älter als 30 Tage sind, in /var/log/meineapp
sudo find /var/log/meineapp -name "*.log" -type f -mtime +30 -delete
```
- Log-Rotation: Stellen Sie sicher, dass logrotate für alle Dienste, die Logs generieren, korrekt konfiguriert ist. Es wird in der Regel täglich ausgeführt und kümmert sich um das Archivieren und Löschen alter Logs.
Leeren Sie den Paketmanager-Cache: Paketmanager behalten oft heruntergeladene Paketdateien. Das Leeren dieser kann erheblichen Speicherplatz freigeben.
- Debian/Ubuntu (apt) :
```
sudo apt autoremove
sudo apt clean
```
- CentOS/RHEL/Fedora (yum/dnf) :
```
sudo yum autoremove  # oder dnf autoremove
sudo yum clean all   # oder dnf clean all
```
Entfernen Sie ungenutzte Pakete: Deinstallieren Sie Software, die Sie nicht mehr benötigen.
- Debian/Ubuntu: sudo apt remove <paketname>
- CentOS/RHEL/Fedora: sudo yum remove <paketname> oder sudo dnf remove <paketname>
Überprüfen Sie temporäre Verzeichnisse: Dateien in /tmp können oft sicher gelöscht werden, insbesondere nach einem Neustart, aber seien Sie vorsichtig, wenn Anwendungen sie aktiv verwenden.
Leeren Sie den Papierkorb: Wenn Sie eine Desktop-Umgebung verwenden, überprüfen Sie die Benutzer-Papierkörbe.
Ziehen Sie eine Größenänderung von Partitionen in Betracht: Wenn der Speicherplatz ständig ein Problem darstellt und die Bereinigung nicht ausreicht, müssen Sie möglicherweise Partitionen in der Größe anpassen oder mehr Speicher hinzufügen. Dies ist ein fortgeschrittenerer Vorgang, der das Aushängen von Partitionen oder das Booten von einer Live-Umgebung erfordern kann.

Seien Sie vorsichtig mit gelöschten Dateien, die noch geöffnet sind. df zeigt möglicherweise ein volles Dateisystem an, selbst nachdem Sie eine große Logdatei entfernt haben, weil ein laufender Prozess noch den Dateihandle geöffnet hat.

sudo lsof +L1

Wenn eine gelöschte Datei noch offen gehalten wird, gibt ein Neustart oder Neuladen des besitzenden Dienstes den Speicherplatz frei. Tun Sie dies absichtlich; starten Sie keine Datenbank oder einen kritischen Dienst mitten in einem Vorfall neu, ohne die Auswirkungen zu verstehen.

Für Journal-Logs bevorzugen Sie die Bereinigung mit journalctl gegenüber dem manuellen Löschen von Dateien:

journalctl --disk-usage
sudo journalctl --vacuum-time=14d

Für Docker-Hosts überprüfen Sie Container-Logs und ungenutzte Images:

docker system df
docker ps --size

Führen Sie auf einem Produktionshost nicht blindlings breite Prune-Befehle aus. Sie können Images, Build-Cache, gestoppte Container und Netzwerke entfernen, von denen jemand erwartet hat, dass sie erhalten bleiben.

Eine Triage-Reihenfolge, die unter Druck funktioniert

Wenn alles langsam ist, verwenden Sie eine feste Reihenfolge, damit Sie nicht zwischen Theorien hin- und herspringen.

Bestätigen Sie, dass der Host erreichbar und nicht schreibgeschützt ist:
```
uptime
date
mount | grep ' ro,'
```
Überprüfen Sie CPU und Last:
```
top
uptime
```
Überprüfen Sie Speicher und Swap:
```
free -h
vmstat 1 5
```
Überprüfen Sie Festplattenspeicher und Inodes:
```
df -h
df -ih
```

Überprüfen Sie aktuelle Kernel- und Dienstfehler:

journalctl -p warning..alert --since "30 minutes ago"
journalctl -k --since "30 minutes ago"

Diese Reihenfolge erfasst die häufigsten Fehler schnell: CPU-Sättigung, Swap-Stürme, volle Dateisysteme, Inode-Erschöpfung, OOM-Kills und Speicherfehler.

Auswahl der am wenigsten schädlichen sofortigen Lösung

Während einer Betriebsunterbrechung benötigen Sie möglicherweise eine kurzfristige Lösung, bevor die dauerhafte Lösung bereit ist.

Bei CPU-Erschöpfung kann ein ordentlicher Neustart des Dienstes sicherer sein als kill -9, insbesondere bei Software, die Zustände schreibt. Wenn ein Hintergrundjob den Benutzerdatenverkehr aushungert, senken Sie seine Priorität:

sudo renice +10 -p <pid>
sudo ionice -c2 -n7 -p <pid>

Bei Speichererschöpfung ist die Reduzierung der Parallelität oft sicherer als das Hinzufügen von Swap und Hoffen. Reduzieren Sie die Anzahl der Web-Worker, pausieren Sie Batch-Jobs oder deaktivieren Sie vorübergehend teure Funktionen. Swap kann Zeit erkaufen, aber starker Swap verwandelt einen klaren Fehler normalerweise in einen langsamen Fehler.

Bei Festplattenerschöpfung löschen oder rotieren Sie Dateien, die Sie verstehen. Gute Kandidaten sind alte komprimierte Logs, Paket-Caches, veraltete Build-Artefakte und temporäre Dateien von gestoppten Jobs. Schlechte Kandidaten sind Datenbankdateien, aktive Logs, unbekannte Dateien unter Anwendungsdatenverzeichnissen und alles, was Sie nicht erklären können.

Aufzuzeichnende Ursachennotizen

Nachdem das System stabil ist, schreiben Sie auf, was sich geändert hat. Nützliche Notizen sind konkret:

Das genaue Dateisystem oder die Ressource, die erschöpft war.
Der beteiligte Prozess, Benutzer, Dienst, Container oder Cron-Job.
Die Befehlsausgabe, die es bewiesen hat.
Die ergriffene Sofortmaßnahme.
Die erforderliche dauerhafte Lösung.

Dies ist kein Selbstzweck. Der nächste Vorfall ist viel einfacher, wenn Sie wissen, dass /var vollgelaufen ist, weil nach einer Bereitstellung Debug-Logs gewachsen sind, oder dass der Speicherdruck begann, als sich die Anzahl der Worker verdoppelte.

Best Practices zur Prävention

Regelmäßige Überwachung: Implementieren Sie eine regelmäßige Überwachung von CPU, Arbeitsspeicher und Festplattenspeicher mit Tools wie top, htop, free, df und dedizierten Überwachungslösungen (z. B. Nagios, Zabbix, Prometheus).
Log-Rotation automatisieren: Stellen Sie sicher, dass logrotate für alle Dienste, die Logs generieren, ordnungsgemäß konfiguriert ist.
Anwendungskonfigurationen optimieren: Optimieren Sie Anwendungseinstellungen, um sie ressourceneffizienter zu machen. Optimieren Sie z. B. Webserver-Worker-Prozesse, Datenbankverbindungspools usw.
Alarme einrichten: Konfigurieren Sie Alarme für anhaltend hohe Auslastung, schnelles Wachstum, OOM-Kills, Dateisystemvollständigkeit, Inode-Erschöpfung und Dienstneustarts. Alarmieren Sie auf Trends, nicht nur auf harte Grenzen.
Systemaktualisierungen: Halten Sie Ihr System und Ihre Anwendungen auf dem neuesten Stand, da Leistungsverbesserungen und Fehlerbehebungen oft in neueren Versionen enthalten sind.
Ressourcengrenzen: Erwägen Sie für Mehrbenutzersysteme oder containerisierte Umgebungen die Festlegung von Ressourcengrenzen (z. B. mit ulimit oder cgroups), um zu verhindern, dass ein einzelner Prozess andere aushungert.

Die Fehlerbehebung bei Ressourcenerschöpfung ist meist diszipliniertes Eingrenzen. Finden Sie die eingeschränkte Ressource, identifizieren Sie den Besitzer, nehmen Sie die kleinste stabilisierende Änderung vor und beheben Sie dann den Grund, warum es passiert ist. Die grundlegenden Werkzeuge reichen für die meisten Vorfälle aus, wenn Sie sie in dieser Reihenfolge verwenden und dem Drang widerstehen, zu löschen oder zu töten, bevor Sie verstehen, was Sie berühren.