Un fichier d’échange ZimaOS volumineux n’est pas la même chose qu’une pression active sur la mémoire virtuelle, et le supprimer n’est pas la bonne façon de récupérer de l’espace sur le disque de démarrage. Vérifiez l’utilisation réelle de la mémoire virtuelle, la pression mémoire, l’espace utilisé par Docker, les journaux et l’emplacement d’AppData avant de modifier la configuration de la mémoire virtuelle.
Le fil de discussion original de 2026 attribuait à tort à un fichier .swap de 3,8 Go le remplissage presque total d’un disque de démarrage de 48 Go, mais les calculs montraient que la mémoire virtuelle ne représentait qu’une petite partie de l’espace manquant. Le système a ensuite récupéré environ 20 Go, ce qui indique plutôt un nettoyage temporaire de Docker ou du cache qu’une réduction de la mémoire virtuelle.
Taille de la mémoire virtuelle réservée et utilisation active
Exécutez :
free -h
swapon --showUn fichier d’échange de 4 Go peut exister sur le disque alors que seule une infime partie est utilisée. Sa taille correspond à une capacité réservée ; cela ne signifie pas que la mémoire vive a débordé de 4 Go.
Déterminer ce qui remplit le disque système
Exécutez :
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -hLes couches d’images Docker, les systèmes de fichiers en écriture, les journaux, les caches et les données temporaires peuvent occuper le petit disque système même lorsque les fichiers multimédias des applications sont associés à un autre emplacement.
Conserver AppData hors du disque système
Le guide actuel sur les données des applications ZimaOS recommande explicitement de définir l’emplacement des données des applications sur un espace de stockage au lieu de remplir le disque système.
Cela n’élimine pas toute l’utilisation de Docker par le système, mais évite que les bases de données des applications et les caches multimédias consomment par défaut le périphérique de démarrage.
Vérifier les journaux des conteneurs
Un conteneur très actif peut faire croître rapidement les journaux JSON. Examinez l’utilisation de l’espace disque par Docker et la taille des journaux des conteneurs avant de supprimer des fichiers au hasard.
Si une application est responsable du problème, corrigez son comportement de journalisation ou faites pivoter les journaux au lieu de supprimer manuellement les fichiers de journaux actifs.
Une utilisation élevée de la mémoire virtuelle peut tout de même indiquer une pression sur la mémoire vive
Si free -h affiche peu de mémoire disponible et que la mémoire virtuelle est activement utilisée, identifiez les processus qui consomment de la mémoire vive. Les bases de données volumineuses, l’indexation de photos, les charges de travail d’IA et les machines virtuelles peuvent forcer un système disposant de peu de mémoire à utiliser la mémoire virtuelle.
Ne désactivez pas la mémoire virtuelle pour masquer le problème
La mémoire virtuelle peut maintenir le système en fonctionnement lors de pics de mémoire temporaires. La désactiver sur un serveur limité en mémoire peut transformer un ralentissement en arrêts forcés dus au manque de mémoire.
Quand ajouter de la mémoire vive
Ajoutez de la mémoire vive lorsque les charges de travail soutenues épuisent régulièrement la mémoire physique et que les services importants utilisent intensivement la mémoire virtuelle. Ne mettez pas à niveau la mémoire vive uniquement parce qu’un fichier d’échange existe.
Le guide de dépannage des performances aide à éviter de considérer tout serveur lent comme un problème de mémoire vive.
Mesurer la pression mémoire au fil du temps
Un seul instantané de free -h peut être trompeur, car Linux utilise délibérément la mémoire vive disponible comme cache. Surveillez la mémoire disponible et vérifiez si les opérations d’entrée et de sortie vers la mémoire virtuelle se poursuivent pendant la charge de travail.
Si les outils disponibles sur le système montrent une utilisation soutenue de la mémoire virtuelle alors que le serveur semble lent, identifiez l’application ou la machine virtuelle qui consomme la mémoire au lieu de vous concentrer uniquement sur la taille du fichier d’échange.
Les images Docker consomment toujours de l’espace système
Déplacer AppData vers /DATA ne déplace pas toutes les couches d’images Docker ni tous les fichiers d’exécution. L’installation et la mise à jour de nombreuses applications peuvent donc augmenter l’espace utilisé sur le disque système, même lorsque tous les volumes de données visibles par l’utilisateur pointent ailleurs.
Avant de lancer un nettoyage, utilisez la vue d’utilisation de l’espace de Docker pour distinguer les images, les conteneurs, les volumes locaux et le cache de compilation. Ne supprimez que les objets dont vous savez qu’ils sont inutilisés.
Vérifier si un petit disque système est le problème structurel
Un disque de démarrage de 48 Go peut convenir, mais il laisse peu de marge pour plusieurs images d’applications, les mises à jour, les journaux et les opérations temporaires. Si le système approche régulièrement les 100 % malgré un nettoyage efficace, un disque système plus grand ou le déplacement d’un plus grand nombre de charges de travail persistantes vers le stockage principal peut constituer une solution durable.
Un espace libre faible peut provoquer des défaillances secondaires
Lorsque la zone système accessible en écriture est presque pleine, les mises à jour des applications, les écritures de bases de données, les journaux et les fichiers temporaires peuvent échouer de manière apparemment unrelated au stockage. Considérez un espace libre très faible comme un risque opérationnel, même si plusieurs téraoctets sont disponibles sur une autre baie.
FAQ
Pourquoi l’espace disque libre est-il revenu pendant la nuit ?
Des couches Docker temporaires, des caches, des journaux ou des tâches de nettoyage ont peut-être libéré de l’espace. Cela ne signifie pas que le fichier d’échange lui-même a diminué.
Dois-je supprimer le fichier .swap ?
Non. Vérifiez d’abord l’utilisation active de la mémoire virtuelle et les éléments qui consomment réellement l’espace disque.
Est-il normal d’avoir 3 à 4 Go de mémoire virtuelle ?
La présence d’un fichier d’échange de quelques gigaoctets n’est pas inhabituelle. Ce qui compte, c’est la quantité de mémoire virtuelle activement utilisée et le caractère durable de la pression mémoire.
Pourquoi mon disque de démarrage est-il toujours utilisé alors qu’AppData se trouve sur /DATA ?
Les métadonnées du moteur Docker, les couches d’images, les systèmes de fichiers d’exécution, les journaux et les fichiers système résident toujours en dehors de vos données d’application associées.
