Combien de RAM et d’espace disque faut-il à Immich ?

De combien de RAM Immich a-t-il besoin ?

Immich demande 6 Go de RAM (mémoire vive) au minimum selon sa documentation, et recommande 8 Go, avec 2 cœurs CPU au minimum et 4 pour une installation confortable. Ce chiffre concerne l’ensemble de la stack, car Immich utilise quatre conteneurs et non une seule application. Parcourir une bibliothèque déjà importée consomme peu de ressources. La mémoire est surtout utilisée pendant l’importation, et la plus grande partie est consommée par un conteneur que vous pouvez désactiver.

[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

Ces chiffres sont ceux publiés sur la page des prérequis d’Immich en octobre 2026. Il s’agit d’une recommandation de dimensionnement, et non d’un contrôle effectué au démarrage du logiciel. La même page documente une configuration plus petite, avec 4 Go et les fonctions de machine learning désactivées, mais rien en dessous. Sur un serveur plus petit, ce qui change est le nombre de tâches en arrière-plan qui vont jusqu’au bout et le comportement d’un import lorsque la mémoire est épuisée.

Il existe une véritable limite matérielle. Depuis la version 3, le conteneur de machine learning sur les hôtes amd64 nécessite un processeur x86-64-v2, ce qui couvre la plupart des processeurs vendus depuis environ 2012. Cette exigence concerne ce conteneur, pas le serveur. Sur du matériel plus ancien, vous pouvez donc désactiver le machine learning, l’exécuter sur une autre machine comme indiqué plus bas ou rester sur la version v2.7.5, que la documentation d’Immich indique comme dernière version compatible.

Si l’installation n’est pas encore faite, commencez par l’installation complète d’Immich sur un VPS avec Docker Compose, puis revenez ici pour dimensionner le serveur.

Où va la mémoire : quatre conteneurs

Le fichier Compose officiel démarre quatre services. Chacun a un profil mémoire différent. Un seul total masque donc l’information utile.

immich-server sert l’interface web et l’API, et exécute également les workers des tâches en arrière-plan. Deux workers s’exécutent dans ce conteneur unique. api traite les requêtes du navigateur et de l’application mobile. microservices exécute les files d’attente, notamment la génération des miniatures et l’encodage vidéo. Les variables IMMICH_WORKERS_INCLUDE et IMMICH_WORKERS_EXCLUDE séparent ces deux éléments dans des conteneurs distincts. Vous pouvez ainsi attribuer sa propre limite mémoire à la partie la plus sollicitée sans limiter celle qui sert vos photos.

database est une image PostgreSQL 14 avec l’extension VectorChord intégrée. Elle contient toutes les métadonnées et un vecteur de recherche par fichier. La documentation d’Immich indique la seule valeur minimale explicite de la stack pour ce service : si vous appliquez des limites de ressources Docker, la base de données a besoin d’au moins 2 GB. La même page recommande de placer la base de données sur un stockage SSD local, et jamais sur un partage réseau, quel qu’il soit. Les recherches dans les vecteurs et les index sont de petites lectures aléatoires. Un volume réseau transforme donc chacune d’elles en aller-retour réseau. Si ce point détermine le choix de l’offre, la différence entre un stockage NVMe et SATA SSD sur un VPS compte davantage ici que partout ailleurs dans cette stack.

redis exécute l’image Valkey et contient les files d’attente des tâches. C’est de loin le plus petit des quatre, car il stocke des enregistrements de tâches plutôt que des données photo.

immich-machine-learning est le service qui détermine la taille de votre offre. Il charge les modèles pour la recherche intelligente, la détection des visages et la reconnaissance de texte. Un modèle chargé reste en mémoire. MACHINE_LEARNING_MODEL_TTL vaut 300 par défaut. Un modèle est donc déchargé après cinq minutes sans requête, puis relu depuis le volume /cache lors de la suivante. Pendant un import en masse, il ne se produit jamais d’intervalle de cinq minutes. Les modèles restent donc chargés du premier fichier au dernier.

Ce qui change pendant un import

Un serveur Immich au repos est silencieux. Les imports sont la principale cause de surcharge sur les petits serveurs, car l’envoi d’un seul asset met en file toute une chaîne de jobs, et plusieurs queues s’exécutent en même temps.

L’extraction des métadonnées lit l’en-tête du fichier et consomme peu de ressources. La génération des thumbnails est plus coûteuse. Immich produit trois thumbnails par asset : un placeholder thumbhash flouté, un aperçu WebP et un thumbnail JPEG, auxquels s’ajoute un thumbnail pour chaque visage détecté. Chacun de ces jobs décode une image, et la concurrence des jobs détermine le nombre d’images décodées simultanément. La concurrence transforme le coût limité de chaque job en charge généralisée pour le serveur. C’est pourquoi la FAQ d’Immich recommande de réduire cette valeur en premier sur une machine aux ressources limitées. Définissez la concurrence des queues lourdes à 1 dans Administration, Settings, Job Settings.

Les assets vidéo ajoutent le transcodage. Chaque job de transcodage est un processus FFmpeg distinct, avec sa propre consommation mémoire. Il utilise tous les threads CPU que vous lui autorisez.

Smart search envoie chaque nouvel asset au conteneur de machine learning afin de calculer un vecteur d’embedding. La détection des visages exécute un second modèle sur la même image. Lors du premier import d’une photothèque existante, ces deux queues traitent chaque asset que vous possédez, pendant plusieurs heures. C’est le moment où la consommation mémoire est la plus élevée sur toute l’installation. Cela ne se produit qu’une seule fois.

Pourquoi la reconnaissance des visages et des objets nécessite le plus de RAM

La gestion des visages comporte deux tâches. La détection des visages exécute un modèle dans le conteneur de machine learning et repère les cadres. La reconnaissance faciale regroupe ensuite ces détections pour identifier les personnes, puis interroge l’index vectoriel dans Postgres. Une grande bibliothèque sollicite donc les deux services successivement : le conteneur de modèles pendant la détection, puis la base de données pendant le regroupement.

Quatre paramètres modifient ce que le conteneur de machine learning conserve en mémoire.

• Le modèle de visages. Immich fournit buffalo_l par défaut, et la FAQ recommande buffalo_s sur un petit serveur. Il s’agit d’un modèle plus petit. Il utilise donc moins de mémoire et s’exécute plus rapidement, au prix d’une moins bonne précision sur les visages de petite taille ou vus de profil.
• Le nombre de workers. MACHINE_LEARNING_WORKERS vaut 1 par défaut. Chaque worker est un processus distinct qui charge sa propre copie des modèles. Le passer à 2 double donc à peu près la mémoire résidente occupée par les modèles. Laissez-le à 1, sauf si vous disposez de RAM en quantité suffisante.
• La taille des lots. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION limite le nombre de visages traités simultanément. Un lot est conservé en mémoire dans son ensemble. Une photo de groupe avec quarante visages consomme donc plus de mémoire qu’un portrait.
• Les types de modèles réellement exécutés. La recherche intelligente, la détection des visages et la reconnaissance de texte chargent chacune leurs propres modèles. La désactivation des fonctions que vous n’utilisez pas, dans Administration, Settings, Machine Learning Settings, libère définitivement la mémoire correspondante, et pas uniquement entre les imports.

Il existe également MACHINE_LEARNING_MODEL_ARENA, documenté comme préallouant la mémoire CPU afin d’éviter la fragmentation, et activé par défaut. Modifiez ce paramètre en dernier. Son effet dépend de l’allocateur mémoire utilisé. La seule manière fiable de l’évaluer consiste donc à surveiller docker stats avant et après la modification.

Trois profils détaillés : 2 GB, 4 GB et 8 GB

[
  {
    "label": "2 GB VPS",
    "server_limit_mb": 768,
    "db_limit_mb": 768,
    "ml_limit_mb": 0,
    "redis_limit_mb": 128,
    "notes": "below every documented configuration, machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 2048,
    "ml_limit_mb": 0,
    "redis_limit_mb": 192,
    "notes": "documented 4 GB setup: machine learning disabled or moved to another host, job concurrency 1"
  },
  {
    "label": "8 GB VPS",
    "server_limit_mb": 2048,
    "db_limit_mb": 2048,
    "ml_limit_mb": 2560,
    "redis_limit_mb": 256,
    "notes": "everything on at default settings"
  }
]

Considérez ces valeurs comme des limites à saisir dans Compose, et non comme une mesure de la mémoire utilisée par Immich. Une limite est un plafond. Elle ne réserve aucune ressource et ne réduit pas la taille d’un service. Elle détermine quel service le kernel tue lorsque le serveur n’a plus de mémoire. Il vaut mieux que cette décision soit prise par vous plutôt que par le système de score du kernel.

Le serveur de 2 GB : supprimer le conteneur de machine learning

2 GB est inférieur au minimum documenté de 6 GB et à la seule configuration réduite documentée par Immich, qui prévoit 4 GB avec le machine learning désactivé. Immich ne publie aucune configuration pour 2 GB. Ce profil est donc un compromis non pris en charge, et non une recette. Si vous essayez malgré tout, commentez l’ensemble du service immich-machine-learning dans docker-compose.yml, ou laissez-le fonctionner et désactivez tous les modèles dans Administration, Settings, Machine Learning Settings. Supprimer le conteneur est l’option la plus efficace, car un modèle désactivé laisse tout de même un processus Python en mémoire.

Vous conservez les uploads, les albums, le partage, la sauvegarde mobile, les miniatures et la recherche par date, lieu et nom de fichier. Vous perdez la recherche par description, le regroupement automatique des visages en personnes et la reconnaissance de texte dans les images.

Les quatre limites totalisent environ 1.7 GB, ce qui laisse environ 300 MB à l’hôte. La documentation d’Immich indique que la base de données nécessite à elle seule au moins 2 GB lorsque des limites de ressources Docker sont utilisées. Cela correspond à la totalité de la mémoire disponible. Les 768 MB attribués à la base de données sont donc nettement inférieurs à ce seuil. C’est pourquoi Postgres est le service le plus susceptible d’être tué ici.

L’import est la première opération à échouer. Afficher une page consiste à interroger les métadonnées et à lire un fichier. Parcourir une bibliothèque déjà importée sollicite donc peu le serveur. En revanche, un import contenant beaucoup de vidéos provoquera du swap, car le transcodage et la file de génération des miniatures ont besoin de mémoire au même moment. Si vous ne disposez que de 2 GB, définissez la concurrence de chaque file d’attente lourde à 1 et ajoutez un fichier de swap. Si vous choisissez une offre, considérez 4 GB comme le véritable minimum.

Le serveur de 4 GB : machine learning activé, un traitement à la fois

Immich indique que 4 GB peuvent convenir avec les fonctionnalités de machine learning désactivées. C’est la seule configuration réduite présentée sur sa page des prérequis. Avec une base de données réglée sur son minimum documenté de 2 GB, les trois limites du tableau totalisent environ 3.2 GB, ce qui laisse environ 800 MB à l’hôte. Définissez la concurrence à 1 pour la génération des miniatures et limitez le nombre de threads de transcodage.

Pour conserver la reconnaissance des visages et des objets, la méthode documentée consiste à exécuter le conteneur de machine learning sur une autre machine, comme indiqué ci-dessous, puis à configurer ce serveur pour l’utiliser. L’exécuter sur le même serveur de 4 GB dépasse ce que documente Immich, car le seuil de 2 GB pour la base de données ne laisse qu’environ 2 GB pour le serveur, Redis, les modèles et l’hôte. Si vous essayez malgré tout, imposez une limite Compose au conteneur de machine learning, activez la reconnaissance faciale avec buffalo_s et définissez la concurrence à 1 pour la génération des miniatures, la détection des visages et la recherche intelligente.

Le premier traitement d’une bibliothèque existante prendra plusieurs heures, et plus d’une journée pour une bibliothèque volumineuse. Il s’agit d’une limite CPU plutôt que mémoire. Ajouter de la RAM ne réduira donc pas sa durée.

Si le machine learning s’exécute sur ce serveur, ce conteneur est le premier à échouer pendant le premier traitement massif. Sans limite, sa consommation augmente pendant qu’un job de transcodage augmente lui aussi, puis le kernel tue le plus volumineux des deux. Comme le conteneur redémarre en quelques secondes, docker ps -a l’affiche Up avec une durée de fonctionnement bien inférieure à celle de ses voisins, et non Exited (137). La file d’attente prend alors discrètement plus de retard qu’auparavant.

Le serveur de 8 GB : la recommandation documentée

8 GB avec 4 cœurs correspond à la recommandation d’Immich. Tout fonctionne alors avec les paramètres par défaut : recherche intelligente, détection des visages, reconnaissance de texte et transcodage, avec la concurrence par défaut. Les bibliothèques de plus de cent mille éléments sont à l’aise sur cette configuration. La contrainte se déplace de la mémoire vers la vitesse du disque, car la base de données consacre l’essentiel de son temps à l’index vectoriel et aux requêtes de métadonnées.

Définissez tout de même les limites. Sur un serveur disposant de marge, elles empêchent une file d’attente hors de contrôle d’entraîner la chute de la base de données. Si vous comparez cette offre aux options plus modestes, le coût réel d’un VPS selon la quantité de mémoire fait généralement de l’offre 8 GB la solution la moins chère pour éviter les réglages permanents.

Limiter la mémoire par service avec les limites Compose

Ne modifiez pas docker-compose.yml. Ce fichier est remplacé à chaque mise à niveau avec wget. Placez les limites dans docker-compose.override.yml, à côté de celui-ci. docker compose les fusionne automatiquement.

services:
  immich-server:
    deploy:
      resources:
        limits:
          memory: 1024M
  immich-machine-learning:
    deploy:
      resources:
        limits:
          memory: 1024M
          cpus: '1.5'
  database:
    deploy:
      resources:
        limits:
          memory: 2048M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

docker stats doit maintenant afficher votre plafond dans la colonne MEM USAGE / LIMIT, au lieu de la mémoire totale de l’hôte. Si la colonne des limites affiche encore la taille totale de l’hôte, le fichier d’override n’a pas été pris en compte. Vérifiez le nom du fichier, puis exécutez docker compose config pour afficher le résultat fusionné.

Conservez au moins 2048M pour la base de données. La documentation d’Immich indique 2 GB comme limite minimale pour la base de données lorsque des limites de ressources Docker sont utilisées. Une limite trop basse transforme un service lent en service arrêté. Augmentez-la si un conteneur redémarre en boucle. Définir des limites mémoire par service dans Docker Compose explique plus en détail le fonctionnement, notamment pourquoi deploy fonctionne avec Compose v2 en dehors de Swarm.

Comment désactiver ou déplacer le conteneur de machine learning

Sur un petit serveur, déplacer ce conteneur ailleurs est le changement qui réduit le plus la charge. Immich permet de l’exécuter sur une autre machine. Créez ce fichier sur le deuxième hôte. Il peut s’agir d’un ordinateur de bureau qui n’est allumé que le soir :

name: immich_remote_ml
services:
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    restart: always
    ports:
      - 3003:3003
volumes:
  model-cache:

docker compose up -d
curl -s http://localhost:3003/ping

Accédez ensuite à Administration, Settings, Machine Learning Settings dans l’interface web. Cliquez sur Add URL, puis saisissez http://<host>:3003. Utilisez la même version sur les deux hôtes. La documentation d’Immich indique que des versions différentes peuvent provoquer des bugs et une instabilité.

Ce port transmet les aperçus des images vers l’autre machine sans chiffrement. La documentation d’Immich précise également que le conteneur de machine learning ne dispose d’aucune mesure de sécurité intégrée. Gardez-le donc sur un réseau privé ou utilisez un tunnel WireGuard entre les deux hôtes. N’exposez jamais 3003 sur Internet.

Si le problème vient du principe même d’un conteneur de modèles résident, il est également pertinent de comparer les différences entre PhotoPrism et Immich concernant les services exécutés en permanence avant de choisir une taille de formule.

De quel espace disque une bibliothèque Immich a-t-elle besoin ?

Il n’existe pas de multiplicateur unique, car quatre éléments différents augmentent à des rythmes différents. Voici le calcul pour une bibliothèque de 50,000 photos et 500 vidéos courtes.

[
  {
    "label": "Originals: 50,000 photos at 4 MB",
    "gb": 200
  },
  {
    "label": "Originals: 500 videos at 120 MB",
    "gb": 60
  },
  {
    "label": "Thumbnails and encoded video at 15%",
    "gb": 39
  },
  {
    "label": "Postgres database",
    "gb": 3
  },
  {
    "label": "Machine learning model cache",
    "gb": 2
  }
]

Les valeurs 200 Go de photos et 60 Go de vidéos sont des hypothèses. Remplacez-les par vos propres moyennes avant d’acheter du matériel, car la vidéo détermine ce chiffre : une minute de vidéo prise avec un téléphone est plus volumineuse qu’une centaine de photos.

find /srv/immich/upload -type f -printf '%s\n' \
  | awk '{n++; s+=$1} END {printf "%d files, %.1f MB average\n", n, s/n/1048576}'

La ligne 39 Go est le seul ratio publié par Immich : les miniatures générées et les vidéos transcodées ajoutent en moyenne 10 à 20 % à la taille de la bibliothèque. Il s’agit d’une plage, car le résultat dépend de la proportion de vos fichiers vidéo qui doivent être réencodés pour assurer la compatibilité avec les navigateurs. Une bibliothèque composée de fichiers JPEG se situe généralement vers le bas de cette plage.

La base de données occupe 3 Go, ce qui correspond presque à un coût fixe. Immich indique que les fichiers de base de données occupent généralement 1 à 3 Go, car ils contiennent des métadonnées et des vecteurs de recherche, pas des pixels. Le cache des modèles occupe 2 Go et augmente si vous activez plusieurs modèles ou si vous en testez différents. La FAQ signale précisément ce volume comme un consommateur d’espace pour cette raison.

Les cinq lignes représentent un peu plus de 300 Go au total. Un volume de 500 Go laisse donc une marge de croissance, contrairement à un volume de 250 Go. Surveillez cette répartition avec :

grep UPLOAD_LOCATION .env
du -sh /srv/immich/*

Six dossiers se trouvent sous UPLOAD_LOCATION. upload et library contiennent les originaux, thumbs contient les aperçus et les miniatures de visages, encoded-video contient les copies réencodées, profile contient les avatars et backups contient les dumps automatiques de la base de données. Seuls upload, library et profile sont irremplaçables, car tout le reste peut être régénéré à partir de ces éléments.

Deux points surprennent souvent. Les fichiers supprimés sont d’abord déplacés dans la corbeille et continuent d’occuper leur espace jusqu’à ce que celle-ci soit vidée. Un nettoyage important ne libère donc aucun espace le jour même. Ensuite, un dump de la base de données ne contient que les métadonnées. Il ne sert à rien sans les fichiers :

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

Associez cette sauvegarde à une copie au niveau des fichiers des originaux vers un emplacement situé hors du serveur. C’est précisément le rôle des sauvegardes restic d’un VPS vers un stockage hors serveur.

Le transcodage est limité par le CPU, pas par la RAM

Ajouter de la RAM n’accélérera pas le transcodage. Immich utilise FFmpeg pour transcoder et, sur un VPS standard, le CPU décode et encode chaque image. Chaque processus FFmpeg conserve également en mémoire des tampons contenant les images décodées. C’est pourquoi la section sur l’import considère un transcodage comme un coût mémoire distinct. En revanche, sa vitesse dépend du CPU. Même lorsque l’accélération matérielle est disponible, Immich précise que seul l’encodage est accéléré par défaut. Le CPU continue donc d’assurer le décodage et le tone mapping, sauf si vous activez également le décodage matériel.

L’accélération matérielle nécessite le fichier Compose supplémentaire hwaccel.transcoding.yml ainsi qu’un périphérique à transmettre, avec NVENC, Quick Sync, RKMPP ou VAAPI. La plupart des offres VPS ne fournissent aucun de ces éléments. Prévoyez donc une charge sur le CPU.

Le paramètre important en pratique est le nombre de threads. Dans Administration, Settings, Video Transcoding Settings, la valeur 0 utilise tous les cœurs. Une seule vidéo peut alors bloquer l’interface web sur une offre à 2 cœurs. Définissez cette valeur sur 1 ou 2, comme le recommande la FAQ d’Immich. Le transcodage sera plus lent, mais il ne perturbera pas le reste du service.

Pourquoi un import qui sature le swap ressemble à un blocage

C’est l’incident que l’on interprète le plus souvent à tort. Quand Immich manque de mémoire, deux situations sont possibles, et une seule ressemble à une panne.

Sans swap, le kernel tue un processus. Le conteneur redémarre en quelques secondes. Dans le navigateur, la file de tâches semble donc simplement s’arrêter, puis reprend. Les éléments à vérifier se trouvent dans docker ps -a :

docker ps -a --filter name=immich
docker inspect immich_machine_learning | grep -i oomkilled
sudo dmesg -T | grep -i -E 'out of memory|oom-kill'

Exited (137) signifie que le processus a été tué avec le signal 9. 137 correspond à 128 plus 9. Cet état n’est visible que lorsque le conteneur est arrêté. Une fois relancé par la restart policy, docker ps -a l’affiche de nouveau comme Up. Une durée d’exécution nettement inférieure à celle des autres conteneurs Immich est alors un indice. Le signal 9 ne prouve pas à lui seul qu’il s’agit d’un problème de mémoire, car Docker l’envoie également lorsqu’un arrêt normal dépasse son délai. Une valeur OOMKilled de true confirme que le conteneur a été tué pour cause de manque de mémoire. Après son redémarrage, les lignes oom-kill de dmesg sont les éléments à retenir.

Avec du swap, rien n’est tué et aucune erreur n’est générée. Le kernel commence à déplacer des pages vers le disque, l’import ralentit d’un ordre de grandeur et l’interface web cesse de répondre dans un délai normal. Tous les conteneurs sont en cours d’exécution. Tous les health checks peuvent encore réussir. Cela ressemble à un blocage. À ce stade, on redémarre souvent la machine, ce qui fait perdre la progression de la file sans rien résoudre.

free -m
vmstat 1 5

Des valeurs non nulles persistantes dans les colonnes si et so de vmstat signifient que la machine lit et écrit continuellement dans le swap : c’est la définition du thrashing. La ligne free -m pour Swap utilisé augmente en parallèle.

Ajoutez tout de même du swap sur une machine de 2 GB ou 4 GB : un import lent que vous pouvez diagnostiquer vaut mieux qu’un conteneur tué dont vous ne pouvez pas déterminer la cause :

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Corrigez ensuite la cause. Réduisez la concurrence des tâches à 1, limitez le conteneur de machine learning ou déplacez-le sur un autre serveur. Le swap vous donne le temps de le faire. Il ne constitue pas une solution à lui seul.

FAQ

Puis-je exécuter Immich sur un VPS de 2 GB ?

Aucune configuration documentée par Immich ne le permet. La page des prérequis indique 6 GB comme minimum, présente 4 GB avec les fonctionnalités de machine learning désactivées comme la seule configuration plus petite, et précise que la base de données seule nécessite au moins 2 GB lorsque des limites de ressources Docker sont utilisées. Commenter le service immich-machine-learning et définir la concurrence des tâches sur 1 peut permettre au service de démarrer, mais cette configuration n’est pas prise en charge. Postgres est alors le service qui risque le plus d’être tué pendant un import. Si vous ne disposez que de 2 GB, ajoutez un fichier swap de 2 GB afin qu’un pic pendant l’import ralentisse le serveur au lieu de provoquer l’arrêt d’un conteneur. Si vous choisissez une offre, commencez avec 4 GB.

Pourquoi mon import Immich s’arrête-t-il sans message d’erreur ?

Deux causes différentes produisent le même résultat dans le navigateur. Soit un conteneur a été tué par manque de mémoire et a déjà redémarré ; dans ce cas, docker ps -a l’affiche Up avec une durée de fonctionnement anormalement courte (Exited (137) apparaît uniquement si vous l’observez pendant son arrêt). Soit l’hôte utilise le swap ; dans ce cas, tous les conteneurs fonctionnent encore et l’ensemble du système est simplement très lent. vmstat 1 5 permet de les distinguer : des valeurs durablement non nulles dans les colonnes si et so indiquent l’utilisation du swap. Dans les deux cas, réduisez la concurrence des tâches pour la génération des miniatures, la détection des visages et la recherche intelligente.

Que signifie le code de sortie 137 dans les journaux Immich ?

137 correspond à 128 plus le signal 9. Le processus a donc été tué avec SIGKILL. Sur un serveur Immich, cela indique généralement une limite de mémoire : soit la limite propre au conteneur, soit l’épuisement de la mémoire de l’hôte. Toutefois, le code seul ne permet pas de le confirmer : Docker envoie également SIGKILL lorsqu’un conteneur ne s’arrête pas avant l’expiration de son délai, fixé par défaut à 10 secondes sous Linux. Vérifiez avec docker inspect immich_machine_learning | grep -i oomkilled. Une valeur de true confirme que le kernel l’a tué pour manque de mémoire. free -m et sudo dmesg -T | grep -i oom-kill indiquent ensuite s’il s’agissait de la limite du conteneur ou de l’ensemble de l’hôte. Le conteneur de machine learning est généralement touché, car il contient habituellement le plus gros processus.

De combien d’espace disque Immich a-t-il besoin par photo ?

Prévoyez la taille du fichier original plus 10 à 20 %. Immich indique que les miniatures générées et les vidéos transcodées augmentent en moyenne la taille de la bibliothèque de 10 à 20 %. La base de données elle-même occupe généralement 1 à 3 GB, même pour une bibliothèque volumineuse. Ce sont les vidéos qui déterminent réellement le volume total. Mesurez donc la taille moyenne de vos propres fichiers avant de choisir une offre, plutôt que d’appliquer un coefficient au nombre de photos.

Ai-je besoin d’un GPU pour Immich ?

Non. Chaque composant d’Immich fonctionne sur CPU. Une carte graphique accélère l’inférence des modèles dans le conteneur de machine learning ainsi que l’encodage vidéo, mais aucun des deux n’est obligatoire. La plupart des offres VPS n’en proposent pas. Sur une machine utilisant uniquement le CPU, définissez le nombre de threads de transcodage sur 1 ou 2, utilisez le modèle de détection des visages buffalo_s et laissez le premier import massif s’exécuter pendant la nuit.