Le comportement initial de forte utilisation du processeur n’était pas simplement dû au fait que « l’indexation normale peut durer indéfiniment ». Après un transfert important, searchd restait à 100 % du processeur pendant des heures — et certains utilisateurs ont signalé plusieurs jours — ce qui faisait monter la température du système et les obligeait à choisir entre arrêter la recherche ou laisser le processeur fonctionner à plein régime.
IceWhale a ensuite fourni une explication précise : un cas particulier occasionnel dans la logique de pagination pouvait provoquer le problème de processeur sollicité pendant une longue durée. Il a été corrigé et optimisé dans ZimaOS 1.3.2-beta2. La même mise à jour a ajouté la mise en veille du moteur de recherche après une période d’inactivité, maintenu l’indexation des noms de fichiers précise et en temps réel, et déplacé l’indexation du contenu des fichiers à minuit avec une utilisation réduite des ressources. La documentation actuelle de la recherche de ZimaOS a depuis évolué, avec une limitation explicite et des valeurs bien plus faibles pour la mémoire et le nombre de services en veille.
searchd monopolisait le processeur après la fin du transfert.La recherche nécessite un index
Zima-Giorgio a d’abord expliqué que la fonction de recherche de Fichiers devait indexer les fichiers. Cette partie était correcte, mais elle n’expliquait pas pourquoi le processeur restait sollicité au maximum pendant une durée inhabituellement longue.
IceWhale a ensuite identifié un cas particulier dans la logique de pagination
Le 11 février 2025, orca-zhang a déclaré que le problème de processeur élevé de longue durée pouvait parfois être causé par une erreur dans la logique de pagination et que le problème avait été corrigé et optimisé dans la version 1.3.2-beta2.
Il s’agit de la conclusion la plus solide de la source et elle devrait remplacer l’explication vague précédente : « l’indexation est en cours ».
La version 1.3.2 a ajouté la mise en veille du service de recherche après inactivité
IceWhale a indiqué que lorsque la recherche n’était pas nécessaire, searchd serait libéré après environ trois minutes d’inactivité, ne laissant que le composant léger zimaos-search service sous les 100 Mo de mémoire et autour de 0 à 1 % du processeur.
L’indexation du contenu a été déplacée à minuit
La même réponse distinguait deux tâches :
- index des noms de fichiers — maintenu aussi précis et en temps réel que possible ;
- index du contenu des fichiers — différé jusqu’à minuit et exécuté avec une faible utilisation des ressources.
Cette distinction existe toujours dans l’architecture actuelle de la recherche.
La recherche actuelle de ZimaOS ajoute des limites explicites aux ressources
La documentation actuelle d’IceWhale décrit :
- surveillance en temps réel des modifications de fichiers et indexation des noms de fichiers ;
- indexation du contenu à minuit ;
- maximum de 100 000 documents par type/session de traitement ;
- durée maximale de traitement de cinq minutes par type ;
- une protection par barrière d’écriture contre les pics d’utilisation du processeur ;
- la réduction de l’utilisation du service et de la mémoire après une période d’inactivité.
Utilisez l’architecture actuelle de la recherche ZimaOS.
La recherche pouvait être désactivée à partir de ZimaOS 1.3.2
orca-zhang a indiqué que la persistance ajoutée à /etc dans la version 1.3.2 permettait aux utilisateurs qui n’avaient pas besoin de la recherche d’exécuter :
systemctl disable zimaos-searchL’arrêt ou la désactivation de la recherche signifie que la recherche de fichiers signalera que le service est indisponible. Les utilisateurs actuels doivent d’abord vérifier le fonctionnement actuel de la recherche avant de désactiver un service essentiel uniquement en raison d’un bug historique.
La capture d’écran « 100 % pleine » de /dev/root concernait un autre problème
Un autre participant a remarqué /dev/root affichait une utilisation de 100 % et a tenté de l’agrandir. IceWhale a expliqué que cette représentation de la racine SquashFS en lecture seule est intentionnelle pour garantir l’intégrité du système et qu’elle ne doit pas être considérée comme une partition racine inscriptible classique nécessitant de l’espace libre.
Ne redimensionnez pas et ne supprimez pas les partitions système de ZimaOS parce que l’image SquashFS indique qu’elle est pleine.
Si la recherche utilise beaucoup de processeur sur la version actuelle de ZimaOS
- confirmer que le système utilise la version stable actuelle de ZimaOS ;
- vérifier si une importation volumineuse de fichiers vient d’avoir lieu ;
- laisser la fenêtre d’indexation documentée se terminer ;
- surveiller si l’utilisation du processeur diminue après la période d’inactivité du service ;
- collecter les informations actuelles
zimaos-searchles journaux si l’utilisation du processeur reste élevée bien au-delà de la période prévue.
FAQ sur l’utilisation élevée du processeur par searchd
Le fait que le processeur soit utilisé à 100 % pendant plusieurs jours était-il considéré comme normal ?
Non. IceWhale a ensuite identifié un cas particulier dans la logique de pagination et l’a corrigé dans la version 1.3.2-beta2.
Quand la version actuelle de ZimaOS effectue-t-elle l’indexation du contenu ?
La documentation actuelle indique que l’indexation du contenu est effectuée pendant les heures creuses, à minuit, tandis que les changements de noms de fichiers sont indexés en temps réel.
La présence de /dev/root à 100 % signifie-t-elle que le disque système n’a plus d’espace libre ?
Ce n’est pas le cas dans la source. IceWhale a expliqué que la représentation SquashFS de la racine système est intentionnellement en lecture seule et qu’il est normal qu’elle apparaisse pleine.
