Pourquoi Immich provoque-t-il une activité répétée du disque pendant la nuit ?

Immich peut générer une activité disque répétée pendant la nuit, car la maintenance planifiée, les opérations sur la base de données, les tâches multimédias en file d’attente ou les nouvelles tentatives se poursuivent après que les utilisateurs ont cessé d’utiliser la bibliothèque.

Un foyer calme ne signifie pas qu’un serveur est inactif. La question utile est de savoir si le même processus et la même tâche expliquent les lectures ou écritures à la même heure. Corrélez d’abord l’activité, puis déterminez s’il s’agit d’un travail attendu, d’un rattrapage de tâches en attente ou d’une boucle qui doit être interrompue.

Associez le pic d’activité disque à l’heure avant de modifier quoi que ce soit

Commencez par relever les horodatages pendant trois nuits plutôt que de vous fier à une seule observation bruyante. Notez quand les E/S de blocs augmentent, quel périphérique est sollicité, si les lectures ou les écritures dominent et si le phénomène commence presque à la même heure. Une heure de début répétitive évoque un planificateur ; un schéma irrégulier indique davantage des arrivées, des nouvelles tentatives ou un autre conteneur.

Les déploiements Immich peuvent planifier des sauvegardes de base de données et des opérations axées sur l’intégrité pendant les heures de faible utilisation ; un pic tôt le matin peut donc être intentionnel. Ne désactivez pas une tâche simplement parce qu’elle réveille les disques. Vérifiez d’abord si une sauvegarde correspondante, un résultat de maintenance ou l’achèvement d’une file d’attente apparaît après la période d’activité.

Le diagnostic ZimaSpace associé sur le travail en arrière-plan d’Immich pendant les heures d’inactivité utilise la même règle des horodatages : reliez le symptôme visible au processus et à la tâche avant de considérer l’« inactivité » comme un état défaillant.

Distinguez les écritures PostgreSQL des lectures multimédias

Les changements d’état de l’application Immich peuvent maintenir PostgreSQL actif même lorsqu’aucune nouvelle photo n’est ouverte. Les points de contrôle de la base de données, la journalisation anticipée, les opérations liées au vacuum et les mises à jour ordinaires de l’application présentent une signature d’E/S différente de celle de l’analyse de milliers de fichiers multimédias. Identifiez le chemin ou le périphérique qui reçoit le trafic avant d’accuser la bibliothèque de photos.

L’analyse de l’observabilité PostgreSQL dans l’analyse de pg_stat_io explique pourquoi il faut distinguer les lectures, les écritures, l’activité du serveur, le comportement du processus de point de contrôle et les écritures en arrière-plan. Utilisez cette distinction pour déterminer si le périphérique de la base de données est sollicité parce que des transactions utiles sont enregistrées ou parce qu’un élément génère continuellement une activité inutile.

Si les écritures de la base de données sont faibles et périodiques tandis que les disques multimédias restent en veille, il peut s’agir d’une maintenance normale de la base de données. Si le même fichier de base de données reçoit des écritures lourdes et continues alors qu’aucune tâche n’avance, conservez les journaux et examinez les requêtes responsables ou la boucle de redémarrage, plutôt que de déplacer toute la bibliothèque vers un stockage plus rapide.

Vérifiez que les files d’attente en arrière-plan progressent réellement

Ouvrez la vue des tâches et comparez les tâches en attente, actives, échouées et terminées avant et après la période nocturne. La génération de miniatures, le traitement vidéo, l’extraction de métadonnées, les tâches d’apprentissage automatique ou le traitement d’une bibliothèque importée peuvent légitimement maintenir le stockage actif après une modification importante. Une file d’attente qui diminue indique un rattrapage utile.

Un rapport récent de la communauté sur des lectures soutenues inexpliquées montre la limite inverse du diagnostic : des lectures très élevées et continues sans travail attendu méritent une investigation, plutôt que d’être considérées comme « normales pour Immich ». Considérez le débit rapporté comme un cas particulier, pas comme une référence.

Si les mêmes tâches échouent et réintègrent la file, l’activité disque peut se répéter sans produire de progrès. Capturez la première erreur et un élément concerné, puis isolez le type de tâche. Ne videz pas toutes les files d’attente et ne régénérez pas toute la bibliothèque avant d’avoir établi si la boucle est due à un fichier, à des permissions, à la latence du stockage ou à une dépendance de service.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Attribuez les E/S à un processus au lieu de deviner à partir du bruit du disque

Utilisez une surveillance des E/S au niveau de l’hôte lors de la prochaine récurrence afin d’identifier le processus qui lit ou écrit sur le périphérique. Reliez ensuite ce processus au serveur Immich, à PostgreSQL, à l’apprentissage automatique, à un outil de sauvegarde, à un antivirus, à une vérification du système de fichiers ou à un conteneur sans rapport. Les voyants des disques et le bruit des ventilateurs ne permettent pas d’établir cette attribution.

Une procédure pratique avec iotop illustre cette méthode centrée sur les processus. Relevez plusieurs échantillons, car une brève rafale peut disparaître entre deux observations ; l’objectif est de capturer le processus pendant la même période que le symptôme.

Si Immich n’est pas le principal responsable des E/S, cessez de modifier ses paramètres et suivez le processus réellement responsable. Si PostgreSQL, Immich ou un processus associé est en cause, corrélez ses journaux et la progression des tâches avec l’échantillon d’E/S. Vous transformerez ainsi « le serveur fait du bruit chaque nuit » en un composant et un déclencheur précis.

Définissez la limite entre un travail nocturne normal et une défaillance

Considérez l’activité comme normale lorsqu’elle commence selon un calendrier connu ou après une modification récente de la bibliothèque, accomplit un travail utile, ne s’accompagne pas d’un nombre croissant d’échecs et que la latence du stockage ainsi que la profondeur des files d’attente reviennent à leur niveau de référence. Notez la durée normale afin de disposer d’un point de comparaison en cas d’augmentation ultérieure.

Une ancienne discussion Immich sur les écritures fréquentes dans la base de données montre pourquoi une certaine activité de la base de données peut exister sans action visible de l’utilisateur. Comme les versions et les déploiements évoluent, utilisez ce cas uniquement pour justifier une mesure séparée de la base de données, et non pour déclarer normales toutes les écritures persistantes.

Faites remonter le problème lorsque les E/S continuent après l’arrêt des files d’attente, que les mêmes erreurs se répètent, que la latence du stockage affecte l’utilisation diurne, que l’espace libre diminue de manière inattendue ou que le phénomène s’amplifie nuit après nuit. Conservez les horodatages, les E/S des processus, le nombre de tâches, les journaux pertinents, l’espace libre du système de fichiers et un déclencheur reproductible avant d’effectuer des modifications invasives.