Quelle limite de mémoire devriez-vous définir pour Immich ?

Ne définissez pas une limite de mémoire pour Immich à partir d’un nombre universel de Go. Une cible de RAM au niveau de l’hôte et une limite par conteneur répondent à des problèmes différents : l’hôte doit pouvoir prendre en charge toute la pile, tandis qu’une limite de conteneur doit protéger l’hôte sans interrompre une charge de travail Immich légitime.

La navigation dans une bibliothèque traitée peut sembler légère, alors qu’un démarrage à froid de l’apprentissage automatique, un import volumineux, la génération de miniatures, l’analyse des visages ou le traitement vidéo consomme beaucoup plus de mémoire. Mesurez la charge de travail la plus exigeante dont vous avez réellement besoin, gardez une marge pour PostgreSQL et le système d’exploitation, et considérez les arrêts OOM répétés comme le signe d’une limite inadéquate plutôt que comme une limitation normale.

Mesurez la pression mémoire avant de choisir la limite

Enregistrez la mémoire dans trois états : navigation au repos, téléversement quotidien représentatif et charge de travail en arrière-plan la plus lourde prévue. Capturez l’utilisation du conteneur, la mémoire disponible de l’hôte, l’activité du swap, les événements OOM et vérifiez si les tâches continuent de progresser. Un seul pic provenant de docker stats ne suffit pas, car la comptabilisation de la mémoire par Linux inclut plusieurs types de mémoire dont le comportement en matière de récupération diffère.

Une répartition de la mémoire du cgroup Docker utile distingue la mémoire anonyme, le cache adossé aux fichiers et la mémoire slab, au lieu de considérer le total brut comme uniformément dangereux. Un cache de fichiers stable avec une marge saine au niveau de l’hôte n’est pas la même chose qu’une mémoire anonyme qui augmente constamment, une pression sur le swap ou un compteur OOM du cgroup qui augmente pendant la même tâche Immich.

Passez à l’étape suivante lorsque vous pouvez identifier un seuil haut reproductible et déterminer s’il s’agit principalement de cache récupérable ou de mémoire de travail active. Si l’utilisation continue d’augmenter avec une charge de travail inchangée, si un conteneur est régulièrement arrêté par OOM ou si l’hôte commence à utiliser intensivement le swap, cessez de dimensionner à partir de cette exécution et diagnostiquez d’abord cette croissance anormale.

Dimensionnez la limite autour de la charge de travail Immich valide la plus lourde

Choisissez la charge de travail qui doit rester prise en charge après l’application de la limite. Pour un foyer, il peut s’agir de quatre téléphones qui téléversent des fichiers pendant que Smart Search et les tâches de reconnaissance faciale rattrapent leur retard ; pour un autre, d’un import initial volumineux suivi d’une navigation normale. Gardez l’ensemble de données, les modèles, les paramètres de concurrence et les autres conteneurs inchangés pendant les mesures afin que la limite corresponde à un engagement de service défini.

Placez la limite stricte au-dessus du pic de mémoire non récupérable observé, avec une marge mesurable suffisante pour les pointes brèves, tout en conservant de la mémoire pour PostgreSQL, le cache du système de fichiers, le moteur de conteneurs et les services indépendants. La liste de contrôle ZimaSpace consacrée aux signes de problèmes de ressources liés à l’IA locale est utile, car la chaleur, le swap et les redémarrages soudains révèlent une pression au niveau de l’hôte qu’un graphique limité à Immich peut ne pas montrer. N’interprétez pas le fait que « le conteneur a atteint la limite une fois » comme la preuve qu’il faut davantage de RAM. Le seuil d’échec important est de savoir si la même charge de travail valide ralentit fortement, perd des tâches, utilise continuellement le swap ou est arrêtée par OOM. À l’inverse, une limite est trop permissive si Immich peut priver la base de données ou l’hôte de ressources avant que son propre cgroup n’atteigne la limite.

Réduisez la charge de travail avant d’augmenter une limite en cas de croissance anormale

Si la limite proposée échoue uniquement pendant un type de tâche en arrière-plan, réduisez la concurrence de cette tâche ou isolez l’étape concernée avant d’augmenter le plafond. L’apprentissage automatique, la génération de miniatures, le traitement vidéo et les opérations de base de données peuvent avoir des profils mémoire différents. Un lot actif plus petit peut s’exécuter plus lentement tout en maintenant l’interface du foyer réactive et l’hôte en mesure de récupérer.

Les défaillances propres à une version sont également importantes. Un rapport concernant la mémoire d’Immich v3.0.3 décrivait un processus d’apprentissage automatique dont la consommation augmentait jusqu’à déclencher un arrêt OOM à la limite du cgroup, après une condition anormale liée aux paramètres régionaux. Ce cas ne définit pas l’utilisation normale de la RAM par Immich ; il montre pourquoi une croissance inexpliquée doit d’abord être traitée comme un problème logiciel ou de configuration avant d’augmenter durablement le budget de l’hôte.

Après avoir modifié une variable de concurrence, de modèle ou de version, relancez la même charge de travail. Ne conservez la modification que si la signature mémoire et la tâche initiale s’améliorent toutes deux dans le sens attendu. Si la mémoire continue d’augmenter sans atteindre un plateau stable, conservez les journaux et les informations de version, puis transmettez le problème au lieu de transformer la limite stricte en un nombre toujours plus élevé.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Validez la limite après un redémarrage à froid et un cycle chargé

Redémarrez l’hôte afin que les caches et la présence des modèles en mémoire repartent d’un état à froid connu. Effectuez les vérifications normales de connexion et de navigation, puis le téléversement représentatif et la charge de travail en arrière-plan. Enregistrez le pic de mémoire anonyme, le cache, le swap, les compteurs OOM, la réactivité de la base de données, le temps nécessaire à la vidange de la file d’attente et vérifiez qu’un autre conteneur important reste réactif.

Une limite acceptable résiste à la fois au démarrage à froid et au cycle normal le plus chargé, sans arrêts OOM, activité intensive et prolongée du swap, redémarrages répétés du conteneur ni file d’attente qui cesse de se vider. Elle doit également laisser suffisamment de marge à l’hôte pour les tâches de récupération, comme une sauvegarde de la base de données ou une connexion d’administration, lorsque Immich est occupé.

Si seul un test de contrainte artificiel échoue alors que toutes les charges de travail domestiques définies réussissent, documentez la limite acceptée au lieu d’acheter de la RAM pour un scénario dont vous n’avez pas besoin.

Si une charge de travail réelle ne peut pas réussir sans épuiser l’hôte, réduisez la concurrence, isolez l’apprentissage automatique, ajoutez de la mémoire ou déplacez les services concurrents ; répétez ensuite la même validation avant de déclarer la nouvelle limite sûre.