Eine große ZimaOS-Swap-Datei ist nicht dasselbe wie aktiver Swap-Druck, und sie zu löschen ist nicht der richtige Weg, um Speicherplatz auf der Boot-Festplatte freizugeben. Prüfe die tatsächliche Swap-Nutzung, den Speicherdruck, die Docker-Festplattennutzung, Protokolle und den Speicherort der AppData, bevor du die Swap-Konfiguration änderst.
Im Quellthread von 2026 wurde eine 3,8-GB-.swap-Datei für eine fast volle 48-GB-Boot-Festplatte verantwortlich gemacht. Die Berechnung zeigte jedoch, dass Swap nur einen kleinen Teil des fehlenden Speicherplatzes ausmachte. Das System gewann später etwa 20 GB zurück, was eher auf die Bereinigung temporärer Docker- und Cache-Daten als auf eine Verkleinerung der Swap-Datei hindeutet.
Reservierte Swap-Größe und aktive Swap-Nutzung
Führe Folgendes aus:
free -h
swapon --showEine 4-GB-Swap-Datei kann auf der Festplatte vorhanden sein, während nur ein winziger Teil davon genutzt wird. Die Dateigröße ist die reservierte Kapazität; sie bedeutet nicht, dass der Arbeitsspeicher um 4 GB übergelaufen ist.
Finde heraus, was die Systemfestplatte füllt
Führe Folgendes aus:
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -hDocker-Image-Layer, beschreibbare Overlays, Protokolle, Caches und temporäre Daten können die kleine Systemfestplatte belegen, selbst wenn Anwendungsmedien an anderer Stelle eingebunden sind.
Halte AppData von der Systemfestplatte fern
Der aktuelle ZimaOS-Leitfaden zu App-Daten empfiehlt ausdrücklich, den Speicherort für App-Daten auf einen Speicherbereich festzulegen, statt die Systemfestplatte zu füllen.
Dadurch wird nicht die gesamte Docker-Systemnutzung beseitigt, aber es verhindert standardmäßig, dass Anwendungsdatenbanken und Medien-Caches das Boot-Laufwerk belegen.
Prüfe die Container-Protokolle
Ein Container mit zu vielen Meldungen kann JSON-Protokolle schnell anwachsen lassen. Prüfe die Docker-Festplattennutzung und die Größe der Container-Protokolle, bevor du wahllos Dateien löschst.
Wenn eine bestimmte App dafür verantwortlich ist, korrigiere ihr Protokollierungsverhalten oder rotiere die Protokolle, anstatt aktive Protokolldateien manuell zu löschen.
Hohe Swap-Nutzung kann weiterhin auf Speicherdruck hindeuten
Wenn free -h nur wenig verfügbaren Speicher anzeigt und Swap aktiv genutzt wird, ermittle, welche Prozesse Arbeitsspeicher verbrauchen. Große Datenbanken, Fotoindizierung, KI-Workloads und VMs können ein System mit wenig Arbeitsspeicher in den Swap zwingen.
Deaktiviere Swap nicht einfach, um das Symptom zu verbergen
Swap kann das System bei kurzfristigen Speicher-Spitzen am Leben halten. Wird Swap auf einem Server mit knappem Arbeitsspeicher deaktiviert, kann sich eine Verlangsamung in das Beenden von Prozessen wegen Speichermangels verwandeln.
Wann du Arbeitsspeicher hinzufügen solltest
Füge Arbeitsspeicher hinzu, wenn dauerhafte Workloads den physischen Speicher regelmäßig vollständig ausschöpfen und wichtige Dienste stark auslagern. Rüste den Arbeitsspeicher nicht allein deshalb auf, weil eine Swap-Datei vorhanden ist.
Der Leitfaden zur Leistungsdiagnose hilft dabei, nicht jeden langsamen Server als Arbeitsspeicherproblem zu behandeln.
Beobachte den Speicherdruck über einen längeren Zeitraum
Eine einzelne Momentaufnahme mit free -h kann irreführend sein, da Linux freien Arbeitsspeicher absichtlich als Cache verwendet. Achte auf den verfügbaren Speicher und darauf, ob während der Workload weiterhin Swap-In- und Swap-Out-Aktivität stattfindet.
Wenn die auf dem System verfügbaren Tools anhaltendes Swapping zeigen, während der Server langsam wirkt, ermittle, welche App oder VM Arbeitsspeicher verbraucht, anstatt dich nur auf die Größe der Swap-Datei zu konzentrieren.
Docker-Images belegen weiterhin Systemspeicher
Das Verschieben von AppData nach /DATA verschiebt nicht jede Docker-Image-Schicht und jede Laufzeitdatei. Durch die Installation und Aktualisierung vieler Apps kann die Systemfestplatte daher wachsen, selbst wenn alle benutzerseitig sichtbaren Daten-Volumes auf einen anderen Speicherort zeigen.
Verwende vor dem Aufräumen die eigene Ansicht zur Docker-Festplattennutzung, um Images, Container, lokale Volumes und den Build-Cache zu unterscheiden. Entferne nur Objekte, von denen du weißt, dass sie nicht verwendet werden.
Prüfe, ob eine kleine Systemfestplatte das grundlegende Problem ist
Eine 48-GB-Boot-Festplatte kann funktionieren, lässt aber wenig Spielraum für mehrere App-Images, Updates, Protokolle und temporäre Vorgänge. Wenn sich das System trotz ordnungsgemäßer Bereinigung wiederholt der 100-%-Marke nähert, kann eine größere Systemfestplatte oder die Verlagerung weiterer persistenter Workloads auf den Hauptspeicher die nachhaltige Lösung sein.
Wenig freier Speicherplatz kann Folgefehler verursachen
Wenn der beschreibbare Systembereich fast vollständig belegt ist, können App-Updates, Datenbankschreibvorgänge, Protokolle und temporäre Dateien auf eine Weise fehlschlagen, die scheinbar nichts mit dem Speicherplatz zu tun hat. Betrachte sehr wenig freien Speicher als Betriebsrisiko, selbst wenn auf einem anderen Array noch Terabytes frei sind.
FAQ
Warum war über Nacht wieder Speicherplatz verfügbar?
Temporäre Docker-Layer, Caches, Protokolle oder Bereinigungsaufgaben haben möglicherweise Speicherplatz freigegeben. Das bedeutet nicht, dass die Swap-Datei selbst kleiner geworden ist.
Sollte ich die .swap-Datei löschen?
Nein. Prüfe zuerst die aktive Swap-Nutzung und die tatsächlichen Verursacher des Speicherplatzverbrauchs.
Sind 3–4 GB Swap normal?
Eine Swap-Datei mit einigen Gigabyte ist nicht ungewöhnlich. Entscheidend ist, wie viel Swap aktiv genutzt wird und ob der Speicherdruck anhält.
Warum wird meine Boot-Festplatte weiterhin genutzt, obwohl sich AppData auf /DATA befindet?
Metadaten der Docker-Engine, Image-Layer, Laufzeit-Overlays, Protokolle und Systemdateien befinden sich weiterhin außerhalb deiner zugeordneten Anwendungsdaten.
