En résumé : « ZimaOS utilise plus de RAM après la version 1.6 » n’est pas assez précis — identifiez le processus ou le conteneur
Le système de 8 Go affichait toujours une utilisation élevée de la mémoire après le passage de la version 1.6.0-beta2 à la version stable. Cela écarte l’explication facile selon laquelle il ne s’agissait que de la surcharge liée à la version bêta. L’étape utile suivante consiste à identifier l’origine : quel conteneur, cache ou processus hôte utilise la mémoire, et le système est-il réellement sous pression ?
Commencez par la mémoire disponible, pas seulement par le pourcentage du tableau de bord
free -h
docker stats --no-stream
ps aux --sort=-%mem | head -20
dmesg | grep -i -E 'oom|out of memory'Linux utilise la RAM autrement inactive pour le cache. Une valeur « utilisée » élevée avec une mémoire available saine et sans pression liée à l’OOM ou au swap diffère d’une fuite. La comptabilisation de la mémoire Linux constitue la référence en amont.
Les totaux des conteneurs n’expliquent qu’une partie de l’hôte
La capture d’écran montre plusieurs conteneurs consommant chacun des centaines de mégaoctets, mais leur addition ne correspond pas nécessairement au total de l’hôte. Les métriques mémoire de Docker, le cache du noyau, le cache de pages et les services qui ne sont pas conteneurisés constituent des couches de comptabilisation distinctes. La documentation de docker container stats explique la vue des conteneurs.
Ne supposez pas que la version stable 1.6.0 inclut un correctif général contre les fuites mémoire
Les notes de version actuelles de la version 1.6.0 mentionnent des correctifs concernant le stockage, le démarrage de Docker, les fichiers et le réseau, mais ne documentent pas de correctif général contre les fuites mémoire. Un diagnostic actuel doit donc rester fondé sur des preuves, plutôt que d’affirmer que « la mise à niveau a résolu le problème ».
La page changements de ZimaOS 1.6 fournit le contexte actuel de la version.
Ce qui constitue une véritable fuite
Surveillez le même processus pendant plusieurs heures. Une fuite est plus probable lorsqu’un processus augmente de manière monotone, que la mémoire disponible diminue, que le swap augmente ou que le noyau commence à arrêter des processus. Si la mémoire se stabilise et que le système reste réactif, il peut simplement s’agir d’un jeu de travail stable plus important.
La page besoins des applications ZimaOS aide à déterminer si l’ensemble des applications installées est simplement trop important pour un hôte de 8 Go.
