Een groot ZimaOS-swapbestand is niet hetzelfde als actieve swapdruk, en het verwijderen ervan is niet de juiste manier om ruimte op de opstartschijf vrij te maken. Controleer het daadwerkelijke swapgebruik, de geheugendruk, het Docker-schijfgebruik, de logboeken en de locatie van AppData voordat je de swapconfiguratie wijzigt.
In de brondiscussie uit 2026 werd een bestand van 3,8 GB met de extensie .swap aangewezen als oorzaak van een bijna volle opstartschijf van 48 GB, maar uit de berekening bleek dat swap slechts een klein deel van de ontbrekende ruimte in beslag nam. Het systeem maakte later ongeveer 20 GB vrij, wat eerder wijst op het opruimen van tijdelijke Docker- of cachegegevens dan op het verkleinen van swap.
Gereserveerde swapgrootte versus actief swapgebruik
Voer het volgende uit:
free -h
swapon --showEr kan een swapbestand van 4 GB op de schijf staan terwijl slechts een klein deel ervan in gebruik is. De grootte van het bestand is gereserveerde capaciteit; dit betekent niet dat het RAM-geheugen met 4 GB is overschreden.
Zoek uit wat de systeemschijf vult
Voer het volgende uit:
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -hDocker-imagelagen, beschrijfbare overlays, logboeken, caches en tijdelijke gegevens kunnen de kleine systeemschijf vullen, ook wanneer applicatiemedia ergens anders zijn gekoppeld.
Houd AppData weg van de systeemschijf
De huidige handleiding voor appgegevens in ZimaOS raadt expliciet aan om de locatie voor appgegevens in te stellen op een opslagruimte, in plaats van de systeemschijf te vullen.
Dit voorkomt niet al het Docker-systeemgebruik, maar zorgt er wel voor dat applicatiedatabases en mediacaches standaard niet de opstartschijf vullen.
Controleer containerlogboeken
Een container die veel logt, kan snel grote JSON-logboeken produceren. Controleer het Docker-schijfgebruik en de grootte van containerlogboeken voordat je willekeurige bestanden verwijdert.
Als één app verantwoordelijk is, los dan het loggedrag op of roteer de logboeken in plaats van actieve logbestanden handmatig te verwijderen.
Veel swapgebruik kan nog steeds wijzen op geheugendruk
Als free -h weinig beschikbaar geheugen toont en swap actief wordt gebruikt, zoek dan uit welke processen RAM verbruiken. Grote databases, foto-indexering, AI-workloads en virtuele machines kunnen een systeem met weinig geheugen in swap dwingen.
Schakel swap niet uit om het symptoom te verbergen
Swap kan het systeem tijdens korte pieken in geheugengebruik draaiende houden. Swap uitschakelen op een server met weinig geheugen kan een vertraging veranderen in het beëindigen van processen wegens geheugentekort.
Wanneer moet je RAM toevoegen?
Voeg RAM toe wanneer langdurige workloads het fysieke geheugen voortdurend uitputten en belangrijke services intensief naar swap schrijven. Breid het RAM-geheugen niet alleen uit omdat er een swapbestand bestaat.
De handleiding voor het oplossen van prestatieproblemen helpt voorkomen dat elke trage server als een RAM-probleem wordt gezien.
Meet geheugendruk over langere tijd
Een enkele momentopname met free -h kan misleidend zijn, omdat Linux vrij RAM-geheugen bewust gebruikt voor caches. Kijk naar het beschikbare geheugen en controleer of er tijdens de workload voortdurend gegevens naar en van swap worden verplaatst.
Als de beschikbare tools op het systeem langdurig swapactiviteit tonen terwijl de server traag aanvoelt, zoek dan uit welke app of virtuele machine geheugen verbruikt in plaats van je alleen te richten op de grootte van het swapbestand.
Docker-images nemen nog steeds systeemruimte in
AppData verplaatsen naar /DATA verplaatst niet elke Docker-imagelaag en elk runtimebestand. Door veel apps te installeren en bij te werken, kan de systeemschijf dus voller raken, ook wanneer alle gegevensvolumes voor gebruikers naar een andere locatie wijzen.
Gebruik vóór het opschonen de eigen weergave van Docker voor schijfgebruik om onderscheid te maken tussen images, containers, lokale volumes en de buildcache. Verwijder alleen objecten waarvan je zeker weet dat ze niet worden gebruikt.
Controleer of een kleine systeemschijf het structurele probleem is
Een opstartschijf van 48 GB kan werken, maar laat weinig ruimte over voor meerdere app-images, updates, logboeken en tijdelijke bewerkingen. Als het systeem ondanks goed opruimen herhaaldelijk bijna 100% vol raakt, kan een grotere systeemschijf of het verplaatsen van meer permanente workloads naar de hoofdopslag de duurzame oplossing zijn.
Weinig vrije ruimte kan secundaire storingen veroorzaken
Wanneer de beschrijfbare systeemruimte bijna vol is, kunnen app-updates, databasebewerkingen, logboeken en tijdelijke bestanden mislukken op manieren die niets met opslag te maken lijken te hebben. Beschouw zeer weinig vrije ruimte als een operationeel risico, zelfs als er op een andere array terabytes beschikbaar zijn.
Veelgestelde vragen
Waarom kwam de vrije schijfruimte 's nachts terug?
Tijdelijke Docker-lagen, caches, logboeken of opruimtaken kunnen ruimte hebben vrijgemaakt. Dat betekent niet dat het swapbestand zelf kleiner is geworden.
Moet ik het bestand .swap verwijderen?
Nee. Controleer eerst het actieve swapgebruik en welke onderdelen daadwerkelijk schijfruimte innemen.
Is 3–4 GB swap normaal?
Het is niet ongebruikelijk dat er een swapbestand van enkele gigabytes bestaat. Belangrijk is hoeveel swap actief wordt gebruikt en of de geheugendruk aanhoudt.
Waarom wordt mijn opstartschijf nog steeds gebruikt als AppData op /DATA staat?
Metagegevens van de Docker-engine, imagelagen, runtime-overlays, logboeken en systeembestanden staan nog steeds buiten de gekoppelde applicatiegegevens.
