Qu’est-ce qui ralentit les recherches ou les résultats de requêtes Immich à mesure que les données augmentent ?
La recherche dans Immich ralentit avec la croissance lorsque les index et les ensembles de travail plus volumineux dépassent les capacités efficaces du cache, du filtrage ou du stockage — et pas simplement parce qu’il y a davantage de photos.
Une bibliothèque plus importante augmente plusieurs volumes à la fois : lignes, représentations vectorielles, métadonnées, miniatures et combinaisons possibles de filtres. Diagnostiquez l’étape qui ralentit, car un stockage de fichiers plus rapide ne peut pas corriger un mauvais chemin de requête, tandis que l’optimisation de la base de données ne peut pas accélérer un montage distant de miniatures.
La croissance étend bien plus que la bibliothèque d’origine
Chaque nouvel élément peut ajouter des lignes à la base de données, des métadonnées extraites, des représentations pour la recherche, des visages, des miniatures et des médias encodés. Ces structures croissent à des rythmes différents et sont consultées différemment. Les téraoctets de la bibliothèque d’origine ne permettent donc pas de prédire la latence de recherche sans connaître le nombre d’entités indexables et d’objets dérivés parcourus par la requête.
L’analyse du chemin des données d’Immich de ZimaSpace sépare le traitement en arrière-plan, les représentations indexables, la sélection dans la base de données et les médias transmis. Pour diagnostiquer les requêtes, elle montre concrètement que la croissance de la bibliothèque modifie à la fois le catalogue indexable et les fichiers présentés après l’obtention d’un résultat, créant ainsi plusieurs sources possibles de ralentissement.
Consignez le nombre d’éléments, la taille de la base de données, la taille de l’index vectoriel, l’empreinte des miniatures et la cardinalité des filtres fréquemment utilisés à chaque étape. Une série chronologique révèle quelle structure croît avec la latence et évite d’attribuer à tort le temps de sélection dans la base de données à une augmentation sans rapport du volume des vidéos originales.
Les index vectoriels deviennent sensibles à l’adéquation avec la mémoire
La recherche sémantique parcourt un index de représentations au lieu de lire chaque image originale. À mesure que cet index grandit, son graphe actif ou ses pages peuvent ne plus rester en mémoire. Les défauts de cache aléatoires transforment alors un traitement à la vitesse de la mémoire en lectures depuis le stockage, ce qui fait augmenter la latence de queue plus fortement que ne le laisse penser l’utilisation moyenne du processeur.
Une analyse technique de la recherche vectorielle dans PostgreSQL explique que les performances de HNSW peuvent se dégrader lorsque le graphe actif dépasse la capacité de la mémoire, car le parcours par accès aléatoires devient sensible aux défauts de cache. Les versions d’Immich et les implémentations d’index pouvant évoluer, utilisez cette analyse comme un mécanisme à vérifier plutôt que comme une prescription de configuration.
Mesurez une requête sémantique fixe après un redémarrage, après un premier échauffement, puis après avoir consulté des régions sans rapport de la bibliothèque. Comparez les lectures de la base de données, le comportement du cache et la latence du périphérique. De forts gains après échauffement qui disparaissent lorsque l’ensemble de travail s’élargit confortent l’hypothèse d’une mémoire insuffisante ; des requêtes uniformément lentes orientent vers une autre cause.
Les filtres et les plans de requête peuvent changer avec la cardinalité
La date, la personne, le propriétaire, l’album et les autres conditions modifient le nombre de candidats restant avant ou pendant le classement. À mesure que la distribution des données évolue, un même filtre visible peut sélectionner une fraction bien plus importante de la bibliothèque. Les statistiques de la base de données et les choix de plan peuvent donc devenir déterminants, même lorsque le terme recherché reste inchangé.
Une analyse des limites de pgvector indique que l’association de la recherche vectorielle à des filtres de métadonnées peut être difficile et que les charges vectorielles partagent le processeur, la mémoire et les entrées-sorties de PostgreSQL avec les opérations transactionnelles. Cet article fournit des éléments généraux sur PostgreSQL : il étaye donc le mécanisme sans prouver l’existence d’un plan de requête donné dans Immich.
Créez des recherches comparées, avec et sans un filtre, à partir d’ensembles de résultats connus. Relevez la durée d’exécution côté serveur et l’activité de la base de données, pas seulement le délai d’affichage dans le navigateur. Si le temps de sélection augmente tandis que les miniatures renvoyées restent rapides, concentrez-vous sur les plans, les statistiques, l’adéquation de l’index et la contention plutôt que sur le stockage des médias.
Séparez la sélection des résultats de leur affichage
L’interface peut sembler lente alors que la base de données a déjà sélectionné les identifiants des éléments correspondants. L’affichage nécessite encore la récupération des miniatures, des lectures sur le stockage, le transfert de la réponse et le décodage côté client. Une arborescence de fichiers dérivés qui s’agrandit ou un montage distant peut ralentir cette seconde phase alors que la requête de recherche elle-même reste saine.
Un témoignage concernant une importation volumineuse décrit un ralentissement général d’Immich tandis que des centaines de milliers de tâches de métadonnées et de miniatures restaient en file d’attente. Il illustre une pression d’arrière-plan concomitante, et non une limite universelle d’échelle, et montre pourquoi les tests de croissance doivent être exécutés à la fois avec des files actives et après leur résorption.
Utilisez les mesures du navigateur ou les observations de l’API pour distinguer la fin de la réception de la réponse contenant les résultats de l’affichage de la dernière miniature visible. Répétez une recherche connue avec les files en pause, puis avec les files actives. Si les identifiants ralentissent, examinez les chemins de la base de données et des index ; si seules les images ralentissent, inspectez le stockage des miniatures, leur transmission réseau, le décodage côté client et les entrées-sorties concurrentes en arrière-plan.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce que l’état d’Immich et quelles parties doivent être persistantes ?
L’état d’Immich comprend les originaux, les relations de la base de données, l’identité, la configuration et les dérivés ; conservez chacun selon qu’il peut...
Comment Immich gère-t-il l’authentification entre les sessions locales et distantes ?
Immich utilise une identité gérée côté serveur avec des sessions client, tandis que les en-têtes de proxy, les origines et les redirections OIDC peuvent...
Pourquoi Immich se comporte-t-il différemment après le redémarrage d’un conteneur ?
Après un redémarrage d’Immich, une perte temporaire du cache est normale ; des problèmes persistants de connexion, de base de données ou de fichiers...
