Comment déterminer si Immich est limité par le processeur, la mémoire vive, le stockage ou le réseau

Déterminez ce qui limite Immich en reproduisant une charge fixe d’importation, de navigation, de recherche ou de tâches en arrière-plan, puis en corrélant son taux d’achèvement avec la saturation du processeur, la pression mémoire, la latence du stockage et le débit réseau sur le même intervalle.

Un pourcentage élevé ne constitue pas à lui seul un goulot d’étranglement : un processeur utilisé à pleine capacité peut fonctionner normalement pendant l’apprentissage automatique, une quantité importante de RAM utilisée peut correspondre au cache du système de fichiers, et un téléversement lent peut être imputable au téléphone ou au Wi-Fi. Mesurez le parcours complet, du client au conteneur et à l’hôte, suivez la progression de la file d’attente, puis modifiez une seule contrainte supposée et recommencez. La ressource dont l’amélioration accélère la même charge est la limite déterminante.

Construisez un test et une chronologie reproductibles

Choisissez le symptôme que vous devez améliorer : importer un lot de fichiers multimédias fixe, ouvrir des originaux non mis en cache, générer des miniatures, exécuter Smart Search ou transcoder une vidéo. Notez le début, le premier résultat exploitable, la fin, les échecs et l’évolution de la file de tâches. Mélanger les tâches produit des graphiques de ressources qui ne permettent aucune décision.

Une enquête d’utilisateur décrit un déploiement Immich anormalement lent, avec une recherche d’éléments sur le processeur, la mémoire, le disque et le réseau. Son cadre de diagnostic interressources est utile, mais votre test fixe doit déterminer la cause sur votre serveur.

Répétez le test une fois les caches réchauffés. Si la deuxième exécution est beaucoup plus rapide, indiquez l’état du cache au lieu de conclure que le matériel est instable. Si les deux exécutions se bloquent au même stade, alignez cet horodatage sur les métriques de l’hôte et du conteneur ainsi que sur la tâche responsable.

Identifiez les signatures du processeur et de la mémoire

Une limitation du processeur se manifeste par une charge exécutable soutenue sur les cœurs concernés, tandis que la tâche progresse proportionnellement ; réduire la concurrence peut améliorer l’interactivité, mais allonger le temps de traitement. Si un thread est saturé alors que l’utilisation totale du processeur semble modérée, consultez la vue par processus et par cœur avant de supposer qu’il reste de la capacité.

Une limitation mémoire nécessite des signes de pression : utilisation croissante du swap, récupération de mémoire, défauts majeurs, arrêts dus à un manque de mémoire ou redémarrages de conteneurs. Une mémoire utilisée importante, avec un cache stable, aucun swap et une latence normale, ne suffit pas à confirmer le problème. Relancez le test avec un worker à concurrence réduite ou un modèle plus petit, puis comparez l’achèvement.

Un cas signalé avec les miniatures d’Immich v2.5.5 a consommé une quantité extrême de mémoire sur un déploiement. Le rapport mémoire limité à cette version justifie de vérifier la tâche défaillante et la version utilisée ; il n’établit pas une exigence normale en RAM.

Différenciez la latence du stockage du débit réseau

Pour le stockage, observez la latence du périphérique, la profondeur de file d’attente, le débit, l’espace disponible du système de fichiers et les inodes disponibles pendant l’exécution exacte de la tâche. Un faible débit en mégaoctets par seconde peut néanmoins indiquer une limitation du stockage lorsque de nombreuses opérations sur la base de données et les miniatures attendent un disque à forte latence.

Pour le réseau, mesurez les deux extrémités, côté client et côté serveur, puis comparez les chemins local et distant. Un lien saturé, des retransmissions, des réessais Wi-Fi ou la limite d’un VPN qui coïncident avec le transfert indiquent une limitation réseau. Si le trafic d’envoi s’arrête alors que le traitement reste lent, suivez plutôt la file d’attente côté serveur.

La présentation de ZimaSpace sur les services à exécuter sur du matériel ancien fournit un contexte de planification système ; ce diagnostic doit toutefois s’appuyer sur la latence et le rythme de traitement observés plutôt que sur l’âge du matériel.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Réduisez une contrainte et vérifiez la même charge

Modifiez une seule variable sans risque : réduisez la concurrence d’une tâche, ajoutez un test temporaire de limite mémoire, déplacez une copie des données actives vers un stockage plus rapide ou testez le réseau local filaire. Conservez un jeu de données, des versions et un état du cache comparables. Une amélioration de l’achèvement et de la métrique prévue valide le lien de causalité.

N’achetez pas de matériel sur la base d’une moyenne à vide ou d’un seul pic. Une ressource mérite une mise à niveau lorsqu’elle contrôle de façon répétée la charge importante après exclusion des erreurs logicielles, des problèmes d’espace libre et des tâches planifiées concurrentes.

Annulez les modifications qui déplacent la panne vers une autre couche ou allongent les files d’attente au-delà de l’objectif de service. Transmettez la définition de la charge, les horodatages, les métriques par conteneur, la latence du disque, les tests réseau, la progression de la file d’attente et les journaux si le système se bloque alors qu’aucune ressource ne montre de pression ; ce schéma peut indiquer un verrou, une dépendance ou une défaillance de l’application.