Pourquoi l’activité en arrière-plan d’Immich augmente-t-elle après une modification de la bibliothèque ?

Les tâches en arrière-plan d’Immich peuvent augmenter fortement après une modification de bibliothèque, car un seul événement lié au système de fichiers ou à la bibliothèque peut se ramifier en tâches d’analyse, de métadonnées, de génération de dérivés et d’indexation.

La distinction importante est celle entre une vague limitée de retraitement attendu et une activité qui revisite continuellement les ressources sans modification correspondante. Le déplacement d’un dossier, une nouvelle analyse d’une bibliothèque externe, la découverte de nouveaux fichiers ou un comportement propre à une version peuvent tous produire des graphiques similaires pour le processeur et les files d’attente. Il faut donc relier l’événement de bibliothèque aux tâches exactes qu’il a créées.

Une analyse de bibliothèque est une étape de découverte, pas l’ensemble de la charge de travail

Une analyse commence par réconcilier ce qu’Immich peut voir sur le disque avec ce qu’il connaît déjà de la bibliothèque. La découverte d’une ressource nouvelle ou modifiée peut ensuite rendre obsolètes ou manquants certains résultats en aval, ce qui crée du travail supplémentaire après la fin apparente de l’analyse.

Un rapport d’utilisateur sur les analyses de bibliothèque simultanées décrit une file d’analyse qui se vide alors que les files des miniatures, de la reconnaissance faciale et d’autres tâches restent fortement chargées. Le mécanisme utile à retenir est la ramification : une courte phase de découverte peut créer une traîne de traitement beaucoup plus longue.

Interprétez les files dans l’ordre des dépendances. Si la file de bibliothèque tombe à zéro tandis que les files de travail dérivé continuent de progresser, le serveur consomme peut-être simplement les tâches produites par l’analyse terminée. Qualifier toute la période de nouvelle analyse répétée masque l’étape qui utilise réellement les ressources.

Les changements de chemin peuvent ressembler à un nouveau traitement des ressources

Les bibliothèques externes sont particulièrement sensibles à l’identité du système de fichiers et aux changements de chemin. Lorsque les fichiers sont réorganisés, l’application peut devoir réconcilier leurs nouveaux emplacements avec l’état enregistré des ressources. Selon le comportement de la version et le type de bibliothèque, cela peut déclencher davantage de travail que ne le laisserait penser le nombre de photos réellement nouvelles.

Une discussion de 2026 sur les fichiers externes déplacés décrit un cas où des chemins réorganisés ont été traités comme de nouvelles ressources, entraînant une nouvelle génération de miniatures ainsi que de nouvelles analyses par apprentissage automatique et de nouveaux traitements vidéo. Il s’agit d’un rapport sur une limitation connue, et non d’une garantie que chaque déplacement de dossier se comporte de la même manière.

Cela explique pourquoi la réorganisation d’une bibliothèque peut être bien plus coûteuse que l’ajout du même nombre de nouvelles photos. Toutefois, si les chemins et le contenu des fichiers n’ont pas changé, une régénération complète répétée indique probablement une autre condition et doit être étudiée plutôt qu’acceptée comme un comportement normal en arrière-plan.

Les files en aval peuvent augmenter alors que le traitement progresse

Le nombre de tâches en attente ne doit pas forcément diminuer de manière monotone. Lorsqu’une tâche se termine, elle peut rendre une ressource éligible à une autre tâche ou ajouter davantage de tâches à une étape ultérieure. Pendant une vaste réconciliation, le serveur peut donc afficher une progression active et une file en aval qui augmente en même temps.

La discussion sur un retard de miniatures indique que de nouvelles tâches de génération peuvent apparaître à mesure que d’autres traitements se terminent. Elle illustre également une limite utile : des bogues historiques et des chemins d’importation mal configurés peuvent créer des boucles pathologiques. Une file qui augmente doit donc être interprétée à la lumière de la version et des chemins concernés.

Utilisez les compteurs de tâches terminées et vérifiez ponctuellement les résultats récents, plutôt que de vous limiter au nombre de tâches en attente. Si les miniatures apparaissent, que le nombre de tâches terminées augmente et que le débit finit par dépasser celui des nouvelles arrivées, la file se vide, même si son maximum est atteint après la fin de l’analyse initiale de la bibliothèque.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Une hausse est anormale lorsque le travail ne correspond à aucune modification

Une charge en arrière-plan attendue doit pouvoir être attribuée à un événement défini : nouvelles ressources, actualisation des métadonnées, changement de chemin, modification d’un modèle ou action explicite de régénération. L’explication devient moins convaincante lorsque les mêmes anciennes ressources sont planifiées à répétition sans changement de configuration ni de contenu.

Un rapport récent dans lequel une analyse affectait d’autres bibliothèques et semblait régénérer du travail dans plusieurs bibliothèques externes montre pourquoi la portée est importante. Considérez ce type de rapport comme un élément de preuve limité à une version, à comparer à vos propres journaux, et non comme le comportement de référence d’Immich.

Ce mécanisme n’explique plus non plus le cas d’un hôte qui reste occupé longtemps après que les files concernées sont vides. Dans ce cas, vérifiez la maintenance de la base de données, les sauvegardes, un autre conteneur, l’activité du système de fichiers ou un processus bloqué. Une modification de bibliothèque ne doit pas devenir une explication fourre-tout pour une charge soutenue sans rapport.

Corrélez la modification avec une cartographie des tâches avant et après

Avant une modification contrôlée de la bibliothèque, relevez le nombre de ressources, le nombre de tâches en attente et actives pour les principales catégories, l’utilisation du processeur, la latence du stockage et l’heure de la dernière analyse terminée. Ajoutez ou déplacez un petit ensemble connu, répétez la même observation et notez précisément quelles files augmentent et à quelle vitesse elles se vident.

Utilisez l’explication de ZimaSpace sur le chemin de données d’Immich pour attribuer chaque hausse à la découverte, au traitement, à la base de données ou au stockage, plutôt que de considérer toute l’activité en arrière-plan comme une seule catégorie.

Considérez la hausse comme normale lorsque le travail généré est proportionnel à la modification contrôlée, que les résultats apparaissent, que les échecs restent limités et que les files reviennent vers leur niveau de référence. Ouvrez une investigation lorsque des ressources inchangées sont régénérées à répétition, que la portée dépasse la bibliothèque modifiée ou que les mêmes tâches échouent sans progression.