Si ZimaOS 1.6.2 entre dans une boucle de redémarrage après une opération portant sur un très grand nombre de fichiers et que icewhale-files ou icewhale-files-backup consomme plusieurs gigaoctets de RAM, mettez à jour vers ZimaOS 1.7.1 ou une version ultérieure avant d’appliquer des masques de service permanents. ZimaOS 1.7.1 a officiellement corrigé l’utilisation anormale de la mémoire dans certains scénarios d’opérations sur les fichiers.
Le rapport d’origine reste utile, car il décrit clairement la chaîne de défaillance : environ 749 000 fichiers ont été copiés, les services de fichiers ont atteint environ 6 Go cumulés sur une machine dotée de 7,5 Go de RAM, le swap a atteint presque 100 % et le serveur redémarrait toutes les 9 à 10 minutes. Le masquage des services a interrompu la boucle, mais a également désactivé l’application web Fichiers et le service de sauvegarde.
Reconnaître le schéma de saturation de la mémoire
Les signes typiques sont notamment :
- RAM presque épuisée ;
- swap presque saturé ;
-
icewhale-filesparmi les processus qui consomment le plus de mémoire ; - une attente d’E/S très élevée ou des blocages apparents du système ;
- des redémarrages répétés ressemblant à ceux provoqués par un watchdog après des opérations portant sur un grand nombre de fichiers.
Étape 1 : Mettre à jour vers ZimaOS 1.7.1 ou une version ultérieure
Les notes de version officielles de ZimaOS 1.7.1 mentionnent explicitement une correction de l’utilisation anormale de la mémoire dans certains scénarios d’opérations sur les fichiers.
Il s’agit de la principale correction actuelle. La solution de contournement pour la version 1.6.2 ne devrait pas constituer votre configuration normale en 2026.
Étape 2 : Mesurer la RAM et le swap
free -h
ps aux --sort=-%mem | head
swapon --showConfirmez que les services de fichiers sont effectivement responsables avant de désactiver quoi que ce soit.
Étape 3 : Vérifier les redémarrages récents
journalctl --list-bootsUn intervalle répétitif peut aider à distinguer le comportement d’un watchdog ou d’une réinitialisation d’une perte d’alimentation aléatoire.
Arrêt d’urgence sur un ancien système 1.6.2
Si le serveur ne peut pas rester actif assez longtemps pour être mis à jour, l’utilisateur à l’origine du rapport l’a stabilisé avec :
sudo systemctl arrêter icewhale-files.service icewhale-files-backup.service
sudo systemctl masquer icewhale-files.service icewhale-files-backup.serviceIl s’agit d’une mesure de récupération d’urgence. Elle désactive des fonctionnalités natives importantes. Après la mise à jour, supprimez les masques et testez normalement les services actuels.
Démasquage après récupération
sudo systemctl démasquer icewhale-files.service icewhale-files-backup.service
sudo systemctl démarrer icewhale-files.service icewhale-files-backup.serviceNe faites cela qu’une fois le système doté d’une version corrigée/actuelle et après avoir obtenu une stabilité suffisante pour observer le comportement de la mémoire.
Un grand nombre de fichiers est différent d’une grande taille de fichier
749 000 petits fichiers peuvent solliciter bien davantage les métadonnées et l’indexation qu’une seule vidéo de 67 Go. Lors de la reproduction ou du signalement du problème, indiquez à la fois le nombre total d’octets et le nombre de fichiers.
NTFS/FUSE et de nombreux conteneurs augmentent la pression
La machine source exécutait également environ 38 conteneurs et utilisait plusieurs volumes NTFS via ntfs-3g. Ces conditions fournissent un contexte, mais ne constituent pas des causes prouvées. Évitez d’en faire la cause racine alors que l’augmentation observée de la mémoire concernait les services de fichiers IceWhale.
N’ajoutez pas un MemoryMax arbitraire comme première solution actuelle
L’auteur de la source a suggéré systemd MemoryMax= comme amélioration du produit. Sur une version récente, limiter artificiellement le service peut provoquer de nouveaux échecs d’indexation ou de sauvegarde si la charge de travail nécessite réellement de la mémoire.
Mettez d’abord à jour, puis mesurez. N’appliquez des limites aux services que si vous comprenez le compromis.
Gardez AppData hors du petit disque système
La saturation de la mémoire peut générer d’importantes E/S temporaires. Le guide de stockage des applications de ZimaOS recommande actuellement de déplacer AppData vers le stockage principal.
Le guide de dépannage des performances fournit une liste de vérifications plus complète des ressources.
FAQ
ZimaOS 1.7.1 a-t-il corrigé ce bug de mémoire ?
Cette version a officiellement corrigé une utilisation anormale de la mémoire dans certains scénarios d’opérations sur les fichiers, ce qui correspond directement au schéma de défaillance observé.
Dois-je masquer définitivement icewhale-files ?
Non. Le masquage était une solution d’urgence qui désactive les fonctionnalités Fichiers et Sauvegarde.
Pourquoi le swap a-t-il aggravé la situation du serveur ?
Lorsque la RAM est épuisée, une pagination intensive peut générer de nombreuses E/S disque et de longs blocages, surtout lorsque les services de fichiers analysent ou copient déjà un très grand nombre de fichiers.
Quelles preuves dois-je recueillir si le problème persiste ?
Version de ZimaOS, nombre de fichiers, taille transférée, état de la RAM/du swap, processus utilisant le plus de mémoire, types de montage/système de fichiers et horodatages des démarrages/redémarrages.
