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

Testez Immich avec une seule opération reproductible, corrélez sa latence avec les attentes liées aux ressources et confirmez le goulot d’étranglement suspecté au moyen d’une intervention contrôlée.

Un instantané du tableau de bord ne permet pas de distinguer l’activité utile de la contention nuisible. Mesurez un point d’accès — par exemple l’acceptation d’un téléversement, l’affichage des miniatures ou la réponse de la recherche intelligente — dans des conditions fixes concernant les médias et le client, puis ne modifiez que la ressource suspectée de limiter les performances.

Définir un point d’accès et une référence reproductible

Commencez par nommer le point d’accès en termes observables. « Immich est lent » ne peut pas être testé, mais « les mêmes vingt miniatures de la timeline mettent quatre secondes à apparaître après un redémarrage » le peut. Fixez le client, le chemin réseau, le compte, le jeu de photos et la condition de départ afin que les exécutions ultérieures ne diffèrent que par une seule variable prévue.

Le modèle de chemin de données d’Immich montre que le téléversement, le traitement, la sélection dans la base de données et la diffusion des médias reposent sur des dépendances différentes. Un test visant la sélection des résultats doit chronométrer séparément la liste de résultats et le rendu des images ; sinon, une requête rapide suivie de lectures de fichiers lentes sera signalée comme un délai unique et indifférencié.

Exécutez la référence au moins trois fois et conservez à la fois la médiane et le percentile utile le plus lent. Enregistrez la profondeur de file d’attente, le processeur par conteneur, la pression mémoire, l’activité du swap, le débit réseau et les retransmissions, la latence du disque ainsi que la profondeur de la file d’attente d’E/S. Toute affirmation concernant un goulot d’étranglement doit faire correspondre le signal de la ressource au délai du point d’accès.

Distinguer la saturation du processeur de la pression mémoire

Lors d’une exécution limitée par le processeur, les tâches prêtes restent en attente de temps processeur ; la latence du point d’accès devrait donc suivre une saturation soutenue des cœurs ou une limitation de fréquence. Lors d’une exécution limitée par la mémoire, on peut plutôt observer de la récupération mémoire, du swap, l’arrêt de conteneurs ou le rechargement répété de modèles. Les deux situations peuvent donner l’impression que les graphiques du processeur sont chargés, mais leurs interventions produisent des réponses différentes.

Un récent guide indépendant des ressources d’Immich répartit l’utilisation entre le serveur, PostgreSQL, Redis et les composants d’apprentissage automatique, au lieu de considérer la RAM totale comme une exigence unique. Cette vue au niveau des services est importante, car une mémoire libre suffisante sur l’hôte peut coexister avec une limite de conteneur trop faible, tandis qu’un cache de fichiers volumineux n’est pas automatiquement le signe d’une saturation.

Vérifiez la pression du processeur en réduisant la concurrence des tâches en arrière-plan ou en attribuant davantage de processeur, tout en maintenant la mémoire constante. Vérifiez la pression mémoire en supprimant l’activité du swap ou en augmentant une limite mémoire restrictive, sans modifier le nombre de tâches parallèles. Si le point d’accès ne s’améliore pas de manière constante, écartez cette ressource comme limite principale pour ce test.

Distinguer le délai réseau du délai de stockage

Les limites réseau et de stockage apparaissent souvent ensemble, car les médias distants traversent les deux. Un lien saturé limite le nombre d’octets transférés par seconde, tandis que la contention du stockage augmente le temps d’achèvement des lectures ou écritures, même lorsque le lien est peu sollicité. Tester uniquement depuis un client distant peut donc attribuer à tort la lenteur de la diffusion des fichiers à la mauvaise couche.

L’analyse de Kingston sur les SSD souligne l’importance des tâches en arrière-plan, du comportement du micrologiciel, de la mise en cache et des commandes de l’hôte, qui influencent la réponse du stockage au-delà du seul débit séquentiel annoncé. Pour Immich, les nombreuses opérations de petite taille sur les miniatures et la base de données rendent la latence et le comportement des files d’attente plus instructifs qu’un simple résultat de bande passante sur un gros fichier.

Répétez le test depuis un client local filaire, puis depuis le chemin distant habituel, sans modifier le jeu de données du serveur. Lisez séparément un ensemble représentatif de fichiers sur l’hôte et surveillez la latence du périphérique. Une amélioration uniquement sur le client local incrimine le chemin réseau ; des attentes persistantes côté hôte incriminent le stockage ou son point de montage.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Utiliser une matrice d’interventions pour accepter ou écarter chaque cause

Rédigez quatre lignes avant les tests : processeur, mémoire, réseau et stockage. Pour chaque ligne, indiquez un symptôme attendu, une intervention ciblée et une condition d’exclusion. Cela empêche le diagnostic de changer après l’apparition des résultats et rend un résultat négatif utile, au lieu d’en faire une raison d’acheter plusieurs mises à niveau à la fois.

Un retour d’expérience public sur Immich, faisant état de miniatures retardées malgré une bande passante Internet importante, montre pourquoi les spécifications seules ne suffisent pas. La preuve pertinente consiste à déterminer si une modification ciblée déplace le point d’accès mesuré, tandis que la cohorte de médias, l’état du cache, les tâches, le client et la version de l’application restent inchangés.

N’acceptez le processeur comme cause que si la réduction de sa charge améliore la latence ; la mémoire uniquement si la réduction de la récupération mémoire produit cet effet ; le réseau uniquement si l’amélioration du chemin réseau le produit ; et le stockage uniquement si la diminution de l’attente du périphérique ou du point de montage le produit. Si deux interventions sont bénéfiques, répétez-les dans les deux ordres, car le deuxième goulot d’étranglement peut ne devenir visible qu’après la suppression du premier.