Immich sur un serveur domestique multi-applications : l’impact des ressources partagées sur les résultats

Les résultats d’Immich varient sur un serveur multifonction, car les conteneurs partagent des ressources limitées en processeur, mémoire, stockage et réseau, malgré des frontières de processus distinctes.

Une recherche de photos peut être rapide à midi et lente pendant la sauvegarde, l’analyse ou le transcodage effectué par une autre application. La configuration d’Immich n’a pas changé, mais le budget de ressources disponible et le contenu des caches, eux, ont changé. Une explication pertinente doit donc prendre en compte la charge de travail complète de l’hôte.

Les conteneurs séparent les processus, pas les capacités physiques

Les conteneurs fournissent des espaces de noms et des limites configurables, mais ils s’exécutent en définitive sur les mêmes processeurs et accèdent généralement au même contrôleur mémoire, aux mêmes disques et aux mêmes interfaces réseau. Un service Immich peut rester dans ses propres limites tout en attendant derrière une tâche sans rapport, sur un périphérique physique partagé ou dans le planificateur du noyau.

Un retour d’expérience sur Immich en conteneurs multiples décrit un hôte peu énergivore exécutant des dizaines de conteneurs avec une utilisation habituelle modérée du processeur. Cela ne garantit pas les mêmes résultats ailleurs ; cela montre pourquoi le seul nombre de services constitue un indice peu fiable et pourquoi il faut observer les tâches qui se chevauchent réellement au niveau de l’hôte.

Répertoriez tous les voisins planifiés ou sujets à des pics d’activité : sauvegardes, analyses multimédias, téléchargements, bases de données et transcodages vidéo. Notez leurs heures de démarrage ainsi que la latence d’Immich. Une corrélation ne prouve pas la causalité, mais une concordance répétée permet de concevoir une expérience contrôlée de mise en pause ou de replanification afin de tester l’interférence supposée.

La concurrence mémoire modifie la présence en cache

Immich est plus performant lorsque les pages de base de données, les miniatures et les données des modèles fréquemment utilisés restent en mémoire. Un service voisin qui augmente son jeu de travail peut évincer ces pages sans provoquer d’erreur de mémoire insuffisante. La requête suivante doit alors payer le coût du stockage ou du chargement du modèle, absent lorsque les données étaient encore en cache.

La discussion de Kingston sur la mémoire des serveurs explique qu’une capacité suffisante réduit le recours à un stockage plus lent pour les applications gourmandes en mémoire. Dans ce contexte, l’idée n’est pas que chaque serveur domestique ait besoin de mémoire de niveau professionnel ; c’est que la perte du cache peut transformer une requête Immich apparemment identique en une charge physique différente.

Comparez l’activité du cache de pages, le swap, les défauts de page majeurs et les lectures du stockage avant et après le démarrage du service voisin. Si sa mise en pause rétablit le comportement des requêtes en cache chaud sans modifier Immich, la présence en mémoire est probablement en cause. Un pourcentage total élevé de mémoire utilisée ne suffit pas à lui seul, car la mise en cache saine du système de fichiers consomme volontairement la mémoire autrement inutilisée.

Les files d’attente du stockage couplent des services sans rapport

Une sauvegarde peut transmettre de gros fichiers en continu pendant qu’Immich effectue de petites opérations sur la base de données et les miniatures. Même lorsque la bande passante globale reste inférieure au maximum annoncé par un disque, la mise en file d’attente peut augmenter le temps d’achèvement des requêtes sensibles à la latence. Un stockage monté sur le réseau ajoute un autre planificateur et un autre chemin réseau à cette même chaîne de contention.

L’article de ZimaSpace sur le chemin des données d’Immich montre que la sélection des résultats et l’affichage des médias sont deux étapes distinctes, avec des dépendances différentes. Cette distinction aide à repérer le couplage du stockage : des identifiants de résultats rapides suivis de miniatures lentes indiquent un problème situé plus loin dans le chemin qu’une sélection de base de données qui serait elle-même lente.

Mesurez la latence du périphérique et la profondeur de sa file d’attente pour chaque point de montage pendant la reproduction de la même requête. Mettez uniquement en pause le voisin supposé gourmand en entrées-sorties, puis répétez le test une fois les caches stabilisés. Si l’amélioration se maintient sur plusieurs exécutions alternées, une séparation du stockage ou une modification de la planification est justifiée ; dans le cas contraire, revenez aux hypothèses concernant le processeur, la mémoire ou le réseau.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilisez un test d’isolement par mise en pause et répétition

Choisissez un point de terminaison fixe, par exemple le chargement de la même fenêtre de chronologie ou l’exécution d’une recherche intelligente connue, et définissez les conditions de cache froid ou chaud. Effectuez trois exécutions avec l’ensemble des services actifs. Mettez ensuite en pause un voisin candidat sans redémarrer Immich, puis répétez la même séquence côté client et pendant la même fenêtre d’observation.

Un retour d’expérience sur la forte concurrence d’Immich pendant un traitement consécutif à une mise à jour décrit un autre service photo qui ne parvenait plus à envoyer des fichiers alors que l’hôte était fortement sollicité. Il s’agit d’une configuration particulière, pas d’une limite universelle, mais cela montre qu’une file d’attente d’arrière-plan saine peut tout de même consommer suffisamment de ressources partagées pour dégrader un autre service interactif.

Ne retenez l’hypothèse d’une interférence que si la mise en pause entraîne une modification reproductible de la latence et si l’attente sur la ressource concernée diminue en parallèle. Testez ensuite une mesure corrective ciblée : réduire la concurrence, définir une plage horaire, appliquer une limite processeur, réserver de la mémoire ou séparer le stockage. Conservez les paramètres permettant un retour en arrière, car l’isolement d’un voisin peut révéler une seconde limite.