Comment Immich planifie l’indexation des recherches lors des importations importantes de bibliothèques mobiles

Lors d’une importation importante depuis une bibliothèque mobile, Immich peut accepter les fichiers plus rapidement que ne se terminent toutes les tâches d’arrière-plan liées à la recherche ; l’actualisation de la recherche peut donc prendre du retard par rapport à la fin des téléversements.

Ce retard relève uniquement de la planification lorsque les tâches requises sont en attente, en cours d’exécution ou en concurrence pour des ressources partagées ; il ne constitue pas automatiquement un échec de la recherche. Le modèle utile est celui d’un pipeline : les fichiers entrants génèrent du travail, les files d’attente absorbent les pics, les processus traitent ces files et la base de données reçoit les résultats dont dépendent les recherches ultérieures.

Les importations importantes créent un pic de tâches différentes

Une migration mobile ne consiste pas seulement à copier des octets. Chaque fichier accepté peut générer des tâches supplémentaires pour les miniatures, les métadonnées, le traitement vidéo, la recherche intelligente, les visages ou d’autres fonctionnalités activées. Comme ces tâches ont des coûts et des dépendances différents, une seule importation peut créer plusieurs retards, avec des vitesses de résorption différentes.

La demande concernant les tâches séquentielles montre pourquoi les utilisateurs remarquent ce comportement sur des hôtes aux ressources limitées : les administrateurs souhaitent parfois que les activités lourdes s’exécutent l’une après l’autre plutôt qu’en parallèle. Cette demande témoigne d’une concurrence entre les ressources, mais ne prouve pas que l’exécution séquentielle soit préférable sur tous les serveurs.

Mesurez chaque file d’attente selon les arrivées, les tâches terminées et les échecs, plutôt que de considérer le nombre total d’éléments en attente comme une seule charge de travail. Un important retard de génération de miniatures peut retarder les autres tâches dépendantes différemment d’un retard de transcodage vidéo, et une file qui diminue régulièrement n’a pas la même signification qu’une file qui réessaie sans cesse les mêmes éléments.

La priorité des files d’attente n’équivaut pas à un contrôle global des ressources

Un système peut donner la priorité à certaines tâches ou les suspendre tout en laissant d’autres types de tâches actifs. C’est pourquoi un outil d’importation qui réduit une catégorie d’activités d’arrière-plan ne garantit pas nécessairement un processeur au repos, des disques silencieux ou une actualisation immédiate de la recherche. La politique de planification et la consommation totale de ressources sont liées, mais ne sont pas identiques.

Une version d’immich-go a introduit des tâches d’arrière-plan suspendues pendant les téléversements afin de réduire les conflits. Ce comportement appartient à cet importateur et à cette version ; il ne faut donc pas en déduire que toute importation mobile avec Immich suspend automatiquement les mêmes tâches.

La limite pratique se mesure à l’avancement observable. Si les téléversements continuent rapidement tandis que les files liées à la recherche restent volontairement suspendues, les nouveaux fichiers deviendront naturellement consultables plus tard. Si la file est activée mais que le nombre de tâches terminées reste proche de zéro, la question ne concerne plus la politique de planification, mais une défaillance du processus, des ressources ou d’un fichier particulier.

La concurrence peut augmenter le débit et nuire à la réactivité

Un plus grand nombre de processus simultanés peut augmenter le nombre de tâches terminées par minute jusqu’à la saturation d’une dépendance partagée. Au-delà, un parallélisme accru peut augmenter l’attente de la base de données, la latence du stockage, la pression mémoire ou les changements de contexte. Le système peut alors terminer plus rapidement les tâches d’arrière-plan en moyenne, tandis que les requêtes interactives subissent une latence de pointe plus élevée.

Le témoignage d’un utilisateur concernant des files de tâches bloquées décrit une grande bibliothèque pour laquelle la réduction de la concurrence a amélioré la progression observée. Il s’agit d’une observation propre à un déploiement, mais elle montre pourquoi la concurrence doit être testée comme une variable de charge plutôt que considérée comme un indicateur fixe des capacités du serveur.

Utilisez comme contrôle interactif une recherche connue portant sur un album déjà indexé. Si cette requête reste rapide tandis que la couverture des nouvelles photos prend du retard, l’importation pose principalement un problème d’actualisation. Si même les anciennes requêtes ralentissent alors que la charge du processeur, du stockage ou l’attente de la base de données augmente, la fenêtre de planification consomme les ressources disponibles pour les interactions.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Une file d’attente qui s’allonge n’est pas automatiquement un problème

Le retard augmente lorsque le travail arrive plus vite que les processus ne terminent les tâches. Lors d’une importation historique volontaire, cela est normal pendant un certain temps. Le signal d’échec n’est pas la longueur maximale de la file en elle-même, mais l’association d’une progression interrompue, d’erreurs répétées ou d’un retard qui ne se résorbe pas après l’arrêt des nouvelles arrivées.

Des discussions sur les importations importantes, comme cette migration de 200 000 photos, montrent comment les administrateurs distinguent le débit de téléversement du traitement en aval. L’expérience de la communauté aide à déterminer quoi mesurer, mais ne doit pas être transformée en estimation universelle du délai pour une autre bibliothèque.

Ce mécanisme n’explique plus l’absence de résultats de recherche lorsque la tâche concernée est terminée et que le même utilisateur autorisé ne parvient toujours pas à retrouver un fichier connu. À ce stade, examinez la pertinence de la requête, les filtres, les autorisations, le comportement du modèle ou le traitement propre au fichier, plutôt que de continuer à ajuster la concurrence de l’importation.

Effectuez un test de planification à deux voies

Créez une voie fixe pour les contenus anciens déjà indexés et une autre pour une petite nouvelle importation. Avant l’importation, mesurez le temps de réponse d’une recherche connue portant sur un contenu ancien. Pendant l’importation, mesurez cette même recherche, le débit de téléversement, le nombre de tâches en attente et terminées, les échecs, la charge du processeur, la pression mémoire et la latence du stockage à intervalles réguliers.

Utilisez l’analyse de ZimaSpace sur le cheminement des données dans Immich pour distinguer les étapes de transfert, de traitement, de stockage et de recherche. Un goulot d’étranglement n’est exploitable que lorsqu’il correspond à l’étape dont l’objectif de service n’est effectivement pas atteint.

Validez la planification si les anciennes recherches restent dans les limites acceptables pour votre foyer, si les files de nouveaux éléments continuent de se vider et si le retard disparaît après l’arrêt des nouvelles arrivées. Réduisez ou replanifiez la concurrence des tâches d’arrière-plan uniquement lorsque le test contrôlé montre que la même ressource partagée retarde à la fois l’utilisation interactive et la progression des files.