Quanta RAM e spazio su disco richiede Immich?

Quanta RAM richiede Immich?

Immich richiede 6 GB di RAM (memoria ad accesso casuale) come minimo documentato e 8 GB come valore consigliato, con 2 core CPU nella configurazione minima e 4 per un'installazione senza problemi. Questo valore si riferisce all'intero stack, perché Immich è composto da quattro container, non da una sola applicazione. Consultare una libreria già importata richiede poche risorse. La memoria viene utilizzata durante l'importazione e, per la maggior parte, da un solo container che è possibile disattivare.

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

Questi sono i valori pubblicati nella pagina dei requisiti di Immich a ottobre 2026. Si tratta di una raccomandazione per il dimensionamento, non di un controllo eseguito dal software all'avvio. La stessa pagina documenta una configurazione più piccola, con 4 GB e le funzionalità di machine learning disattivate, ma non indica valori inferiori. Su un server più piccolo cambiano i job in background che riescono a terminare e il comportamento dell'importazione quando la memoria si esaurisce.

Esiste un solo limite tecnico effettivo. Dalla versione 3, il container di machine learning sugli host amd64 richiede una x86-64-v2 CPU, caratteristica presente nella maggior parte dei processori venduti dal 2012 circa. Il requisito riguarda quel container, non il server. Sull'hardware più vecchio è quindi possibile disattivare il machine learning, eseguirlo su un'altra macchina come descritto di seguito oppure usare v2.7.5, che la documentazione di Immich indica come ultima versione compatibile.

Se non hai ancora eseguito l'installazione, inizia da installazione completa di Immich su un VPS con Docker Compose e torna qui per dimensionare il server.

Dove finisce la memoria: quattro container

Il file Compose ufficiale avvia quattro servizi. Ognuno ha un profilo di utilizzo della memoria diverso, quindi un unico totale nasconde la parte utile.

immich-server fornisce l'interfaccia web e l'API, oltre a eseguire i worker dei processi in background. Due worker risiedono nello stesso container. api gestisce le richieste provenienti dal browser e dall'app mobile. microservices esegue le code, inclusa la generazione delle miniature e la codifica video. Le variabili IMMICH_WORKERS_INCLUDE e IMMICH_WORKERS_EXCLUDE separano questi due componenti in container distinti. In questo modo puoi assegnare un limite di memoria autonomo al componente più oneroso, senza limitare quello che serve le tue foto.

database è un'immagine PostgreSQL 14 con l'estensione VectorChord integrata. Contiene tutti i metadati e un vettore di ricerca per ogni risorsa. La documentazione di Immich assegna a questo servizio l'unico requisito minimo esplicito dello stack: se applichi limiti alle risorse Docker, il database richiede almeno 2 GB. La stessa pagina indica che il database dovrebbe risiedere preferibilmente su storage SSD locale e mai su una condivisione di rete di alcun tipo, perché le ricerche nei vettori e negli indici consistono in piccole letture casuali; un volume di rete trasforma quindi ogni operazione in un round trip. Se la scelta del piano dipende da questo aspetto, la differenza tra storage NVMe e SSD SATA su un VPS è più importante qui che in qualsiasi altro componente dello stack.

redis esegue l'immagine Valkey e contiene le code dei processi. È di gran lunga il più piccolo dei quattro, perché memorizza i record dei processi e non i dati delle foto.

immich-machine-learning è il servizio che determina le dimensioni del piano. Carica i modelli per la ricerca intelligente, il rilevamento dei volti e il riconoscimento del testo, e un modello caricato rimane residente in memoria. MACHINE_LEARNING_MODEL_TTL ha come valore predefinito 300, quindi un modello viene rimosso dopo cinque minuti senza richieste e riletto dal volume /cache alla richiesta successiva. Durante un'importazione in blocco non trascorrono mai cinque minuti tra due richieste, quindi i modelli restano caricati dalla prima risorsa all'ultima.

Cosa cambia durante un'importazione

Quando è inattivo, Immich usa poche risorse. Le importazioni possono mandare in crisi i server di piccole dimensioni, perché il caricamento di un singolo asset accoda una catena di job e diverse code vengono eseguite contemporaneamente.

L'estrazione dei metadati legge l'header del file e richiede poche risorse. La generazione delle miniature è più pesante. Immich produce tre miniature per ogni asset: un segnaposto thumbhash sfocato, un'anteprima WebP e una miniatura JPEG, oltre a una miniatura aggiuntiva per ogni volto rilevato. Ognuno di questi job decodifica un'immagine e la concorrenza dei job determina quante immagini vengono decodificate contemporaneamente. La concorrenza è il moltiplicatore che trasforma un costo ridotto per job in un carico esteso a tutto il server. Per questo la FAQ di Immich indica la concorrenza come il primo parametro da ridurre su una macchina con risorse limitate. Imposta a 1 la concorrenza delle code più pesanti in Administration, Settings, Job Settings.

Gli asset video aggiungono la transcodifica. Ogni job di transcodifica è un processo FFmpeg separato, con la propria memoria, e utilizza tutti i thread della CPU che gli consenti di usare.

Smart search invia ogni nuovo asset al container di machine learning per calcolare un vettore di embedding. Il rilevamento dei volti esegue un secondo modello sulla stessa immagine. Durante la prima importazione di una libreria di foto esistente, entrambe le code elaborano ogni asset disponibile per ore. Questo è il momento in cui il consumo di memoria raggiunge il valore massimo nell'intera installazione, e si verifica una sola volta.

Perché il riconoscimento dei volti e degli oggetti richiede più RAM

La gestione dei volti comprende due attività. Il rilevamento dei volti esegue un modello nel container di machine learning e individua i riquadri. Il riconoscimento facciale raggruppa quindi questi rilevamenti associandoli alle persone e, durante questa fase, interroga l'indice vettoriale in Postgres. Una libreria di grandi dimensioni sollecita quindi entrambi i servizi in sequenza: prima il container del modello durante il rilevamento, poi il database durante il raggruppamento.

Quattro impostazioni modificano il contenuto del container di machine learning.

• Il modello dei volti. Immich include buffalo_l per impostazione predefinita e la FAQ consiglia buffalo_s sui server di dimensioni ridotte. È un modello più piccolo, quindi occupa meno memoria ed è più veloce, ma può essere meno accurato sui volti piccoli o ripresi di profilo.
• Il numero di worker. MACHINE_LEARNING_WORKERS ha come valore predefinito 1. Ogni worker è un processo separato che carica una propria copia dei modelli; portarlo a 2 raddoppia circa la memoria residente dei modelli. Lascialo impostato su 1, a meno che non disponga di RAM sufficiente.
• La dimensione del batch. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION limita il numero di volti elaborati contemporaneamente. Un batch viene mantenuto interamente in memoria, quindi una foto di gruppo con quaranta volti richiede più memoria di un ritratto.
• I tipi di modello effettivamente utilizzati. La ricerca intelligente, il rilevamento dei volti e il riconoscimento del testo caricano ciascuno i propri modelli. Disattivando quelli che non utilizzi, in Administration, Settings, Machine Learning Settings, la memoria viene liberata in modo permanente e non soltanto tra un'importazione e l'altra.

È disponibile anche MACHINE_LEARNING_MODEL_ARENA, documentato come impostazione che prealloca la memoria della CPU per evitare la frammentazione e attiva per impostazione predefinita. Modificala per ultima. Il suo effetto dipende dall'allocatore di memoria sottostante; l'unico modo affidabile per valutarlo è monitorare docker stats prima e dopo la modifica.

Tre profili pratici: 2 GB, 4 GB e 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"
  }
]

Considerali limiti da inserire in Compose, non misurazioni delle risorse utilizzate da Immich. Un limite è un tetto massimo. Non riserva risorse e non riduce le dimensioni di un servizio. Stabilisce quale servizio il kernel terminerà quando il server esaurisce la memoria, una decisione che è preferibile affidare a te anziché al sistema di valutazione interno del kernel.

Il server da 2 GB: rimuovere il container di machine learning

2 GB sono al di sotto del minimo documentato di 6 GB e anche al di sotto dell'unica configurazione ridotta documentata da Immich, cioè 4 GB con il machine learning disabilitato. Immich non pubblica alcuna configurazione da 2 GB, quindi questo profilo è un compromesso non supportato, non una procedura consigliata. Se vuoi provarlo comunque, commenta l'intero servizio immich-machine-learning in docker-compose.yml oppure lascialo in esecuzione e disabilita tutti i modelli in Administration, Settings, Machine Learning Settings. Rimuovere il container è l'opzione più efficace, perché un modello disabilitato lascia comunque in memoria un processo Python.

Mantieni upload, album, condivisione, backup da dispositivi mobili, miniature e ricerca per data, luogo e nome file. Perdi la ricerca per descrizione, il raggruppamento automatico dei volti nelle persone e il riconoscimento del testo nelle immagini.

I quattro limiti ammontano a circa 1.7 GB e lasciano all'host circa 300 MB. La documentazione di Immich indica che il solo database richiede almeno 2 GB quando sono attivi i limiti delle risorse Docker, cioè l'intera memoria disponibile sul server. Di conseguenza, 768 MB per il database sono nettamente inferiori a questa soglia, ed è per questo che Postgres è il servizio con maggiore probabilità di essere terminato.

Il primo problema si verifica durante l'importazione. La visualizzazione di una pagina richiede una query sui metadati e la lettura di un file, quindi consultare una libreria già importata esercita un carico limitato sul server. Un'importazione con molti video, invece, usa la swap, perché transcodifica e coda delle miniature richiedono memoria nello stesso momento. Se disponi soltanto di 2 GB, imposta la concorrenza di tutte le code pesanti su 1 e aggiungi un file di swap. Se stai scegliendo un piano, considera 4 GB come soglia minima effettiva.

Il server da 4 GB: machine learning attivo, un'attività alla volta

Immich documenta 4 GB come configurazione utilizzabile con le funzioni di machine learning disabilitate, ed è l'unica configurazione ridotta indicata nella pagina dei requisiti. Con il database impostato alla soglia documentata di 2 GB, i tre limiti nella tabella ammontano a circa 3.2 GB e lasciano all'host circa 800 MB. Imposta la concorrenza dei lavori su 1 per la generazione delle miniature e mantieni basso il numero di thread per la transcodifica.

Per mantenere il riconoscimento dei volti e degli oggetti, la procedura documentata consiste nell'eseguire il container di machine learning su un altro computer, come descritto di seguito, e configurare questo server per utilizzarlo. Eseguirlo sullo stesso server da 4 GB supera quanto documentato da Immich, perché la soglia minima del database lascia circa 2 GB complessivi per il server, Redis, i modelli e l'host. Se vuoi provarlo comunque, applica un limite Compose al container di machine learning, imposta il riconoscimento facciale su buffalo_s e configura la concorrenza dei lavori su 1 per la generazione delle miniature, il rilevamento dei volti e la ricerca intelligente.

La prima analisi di una libreria esistente richiede molte ore e, per una libreria di grandi dimensioni, più di un giorno. Si tratta di un limite della CPU, non della memoria, quindi aggiungere RAM non la renderà più breve.

Se il machine learning viene eseguito su questo server, il primo problema riguarda il relativo container durante la prima analisi completa. Senza un limite, il suo consumo cresce mentre cresce anche un lavoro di transcodifica e il kernel termina il processo più grande tra i due. Poiché il container viene riavviato entro pochi secondi, docker ps -a lo mostra Up con un uptime molto più breve rispetto ai servizi vicini, anziché Exited (137), mentre la coda procede silenziosamente più lentamente rispetto all'ultima verifica.

Il server da 8 GB: la configurazione consigliata dalla documentazione

8 GB con 4 core corrispondono alla configurazione consigliata da Immich e tutto funziona con le impostazioni predefinite: ricerca intelligente, rilevamento dei volti, riconoscimento del testo e transcodifica, con concorrenza predefinita. Le librerie con più di centomila risorse funzionano senza problemi in questo scenario e il collo di bottiglia si sposta dalla memoria alla velocità del disco, perché per il database l'indice vettoriale e le query sui metadati sono le attività principali durante tutta la giornata.

Imposta comunque i limiti. Su un server con risorse disponibili, i limiti impediscono a una coda fuori controllo di causare anche l'arresto del database. Se stai confrontando questo piano con le opzioni più piccole, quanto costa davvero un VPS in base alla quantità di memoria rende solitamente il piano da 8 GB il modo più economico per evitare continue regolazioni.

Come limitare la memoria per servizio con i limiti di Compose

Non modificare docker-compose.yml. Quel file viene sostituito ogni volta che aggiorni con wget. Inserisci i limiti in docker-compose.override.yml, accanto a quel file; docker compose li unisce automaticamente.

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 dovrebbe ora mostrare il limite impostato nella colonna MEM USAGE / LIMIT, invece della memoria totale dell'host. Se la colonna dei limiti mostra ancora la memoria totale dell'host, il file di override non è stato caricato. Controlla il nome del file ed esegui docker compose config per visualizzare il risultato dell'unione.

Mantieni il database a 2048M o oltre. La documentazione di Immich indica 2 GB come limite minimo per il database quando vengono usati i limiti delle risorse Docker. Un limite troppo basso trasforma un servizio lento in un servizio non funzionante. Aumentalo se un container entra in un ciclo continuo di riavvii. Per maggiori informazioni sul funzionamento, consulta impostare i limiti di memoria per servizio in Docker Compose, incluso il motivo per cui deploy funziona con Compose v2 anche al di fuori di Swarm.

Come disattivare o spostare il container di machine learning

Su un server di piccole dimensioni, spostare questo container altrove è la modifica singola più significativa che si possa applicare. Immich supporta l'esecuzione del container su un altro computer. Crea questo file sul secondo host, che può essere un desktop acceso soltanto la sera:

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

Poi apri Administration, Settings, Machine Learning Settings nell'interfaccia web, fai clic su Add URL e inserisci http://<host>:3003. Mantieni la stessa versione su entrambi gli host, perché la documentazione di Immich avverte che una mancata corrispondenza tra le versioni può causare bug e instabilità.

Quella porta trasferisce le anteprime delle foto all'altro computer senza cifratura. La documentazione di Immich avverte inoltre che il container di machine learning non dispone di misure di sicurezza proprie. Mantienilo quindi su una rete privata oppure eseguilo tramite un tunnel WireGuard tra i due host. Non esporre mai la porta 3003 a Internet.

Se il problema è la presenza permanente di un container con il modello, è anche ragionevole confrontare le differenze tra PhotoPrism e Immich rispetto ai componenti in esecuzione a riposo prima di scegliere un piano.

Quanto spazio su disco richiede una libreria Immich?

Non esiste un unico moltiplicatore, perché quattro componenti diverse crescono a ritmi diversi. Ecco il calcolo per una libreria con 50,000 foto e 500 video brevi.

[
  {
    "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
  }
]

I 200 GB di foto e i 60 GB di video sono ipotesi. Sostituiscili con le tue medie prima di acquistare l’hardware, perché sono i video a determinare questo valore: un minuto di video registrato con il telefono occupa più spazio di cento foto.

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 riga 39 GB è l’unico rapporto pubblicato da Immich: le miniature generate e i video transcodificati aggiungono in media dal 10 al 20 percento alle dimensioni della libreria. Si tratta di un intervallo perché dipende dalla quantità di risorse video che devono essere ricodificate per garantire la compatibilità con il browser. Una libreria composta da file JPEG si avvicina al limite inferiore dell’intervallo.

Il database occupa 3 GB, un costo quasi fisso. Immich indica in genere da 1 a 3 GB per i file del database, perché contengono metadati e vettori di ricerca, non pixel. La cache dei modelli occupa 2 GB e cresce se abiliti più modelli o ne provi di diversi. Le FAQ indicano questo volume come una voce che può consumare spazio proprio per questo motivo.

Le cinque righe totalizzano poco più di 300 GB, quindi un volume da 500 GB lascia spazio per la crescita, mentre uno da 250 GB non è sufficiente. Controlla la suddivisione con:

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

Sei directory si trovano sotto UPLOAD_LOCATION. upload e library contengono gli originali, thumbs contiene le anteprime e le miniature dei volti, encoded-video contiene le copie ricodificate, profile contiene gli avatar e backups contiene i dump automatici del database. Solo upload, library e profile sono insostituibili, perché tutto il resto può essere rigenerato a partire da questi dati.

Due aspetti sorprendono spesso gli utenti. Le risorse eliminate vengono prima spostate nel cestino e continuano a occupare spazio finché il cestino non viene svuotato, quindi una pulizia significativa non libera spazio il giorno stesso in cui la esegui. Inoltre, un dump del database contiene solo metadati, quindi è inutilizzabile senza i file:

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

Affianca a questo una copia a livello di file degli originali in una posizione esterna al server, che è lo scopo dei backup restic da un VPS verso uno storage esterno.

La transcodifica è limitata dalla CPU, non dalla RAM

Aggiungere RAM non rende più veloce la transcodifica. Immich esegue la transcodifica con FFmpeg e, su un VPS senza accelerazione hardware, ogni fotogramma viene decodificato e codificato dalla CPU. Ogni processo FFmpeg mantiene comunque in memoria i buffer dei fotogrammi decodificati. Per questo la sezione sull'importazione considera ogni transcodifica un costo di memoria distinto. La velocità, però, dipende dalla CPU. Anche quando l'accelerazione hardware è disponibile, la documentazione di Immich indica che, per impostazione predefinita, viene accelerata soltanto la codifica. La CPU continua quindi a occuparsi della decodifica e del tone mapping, a meno che non si abiliti anche la decodifica hardware.

L'accelerazione hardware richiede il file Compose aggiuntivo hwaccel.transcoding.yml e un dispositivo da esporre al container, usando NVENC, Quick Sync, RKMPP o VAAPI. La maggior parte dei piani VPS non offre nessuna di queste opzioni. È quindi necessario pianificare l'utilizzo della CPU.

L'impostazione pratica riguarda il numero di thread. In Administration, Settings, Video Transcoding Settings, un valore di thread pari a 0 indica l'utilizzo di tutti i core. Su un piano con 2 core, questo può bloccare l'interfaccia web durante la transcodifica di un video. Impostare invece il valore su 1 o 2, come suggerito dalle FAQ di Immich. In questo modo la transcodifica sarà lenta, ma non comprometterà il funzionamento del servizio.

Perché un’importazione con thrashing della swap sembra bloccata

Questo è il problema che viene interpretato erroneamente più spesso. Quando Immich esaurisce la memoria, si verificano due scenari e solo uno dei due sembra un errore.

Senza swap, il kernel termina un processo. Il container si riavvia in pochi secondi, quindi nel browser la coda dei job si arresta semplicemente e poi riprende. Le prove sono in 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) indica che il processo è stato terminato con il segnale 9. 137 è 128 più 9. Questo stato è visibile solo mentre il container è arrestato. Dopo che la policy di riavvio lo ha riportato in esecuzione, docker ps -a lo mostra di nuovo Up e un uptime molto più breve rispetto agli altri container Immich è l’indizio. Il segnale 9, da solo, non dimostra un problema di memoria, perché Docker lo invia anche quando un arresto normale supera il timeout. Un valore OOMKilled pari a true conferma che il processo è stato terminato per esaurimento della memoria e, dopo il riavvio del container, le righe oom-kill di dmesg sono il registro da considerare attendibile.

Con la swap, non viene terminato alcun processo e non si verifica alcun errore. Il kernel inizia a spostare le pagine sul disco, l’importazione rallenta di un ordine di grandezza e l’interfaccia web smette di rispondere entro un timeout normale. Tutti i container sono in esecuzione. Anche tutti gli health check possono continuare a passare. Sembra un blocco e a questo punto spesso si riavvia il server, perdendo l’avanzamento della coda senza modificare la situazione.

free -m
vmstat 1 5

Valori diversi da zero mantenuti nelle colonne si e so di vmstat indicano che la macchina legge e scrive continuamente sulla swap, che è la definizione di thrashing. Anche la riga free -m relativa a Swap usata aumenterà nello stesso momento.

Aggiungi comunque la swap su una macchina da 2 GB o 4 GB, perché un’importazione lenta che puoi diagnosticare è preferibile a un container terminato che non puoi diagnosticare:

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

Poi correggi la causa. Riduci la concorrenza dei job a 1, limita il container di machine learning oppure spostalo su un altro host. La swap ti concede il tempo necessario per farlo. Da sola non è la soluzione.

FAQ

Posso eseguire Immich su un VPS da 2 GB?

Non con una configurazione documentata da Immich. La pagina dei requisiti indica 6 GB come quantità minima, cita 4 GB con le funzionalità di machine learning disabilitate come unica configurazione più piccola e specifica che, quando vengono usati i limiti delle risorse Docker, solo il database richiede almeno 2 GB. Commentare il servizio immich-machine-learning e impostare la concorrenza dei job su 1 può consentire l'avvio, ma si tratta di un compromesso non supportato e Postgres è il servizio che ha più probabilità di essere terminato durante un'importazione. Se disponi soltanto di 2 GB, aggiungi un file di swap da 2 GB: in questo modo un picco durante l'importazione rallenta il server invece di causare la terminazione di un container. Se devi scegliere un piano, parti da 4 GB.

Perché l'importazione di Immich si interrompe senza mostrare messaggi di errore?

Dal browser, due cause diverse hanno lo stesso aspetto. Un container potrebbe essere stato terminato per esaurimento della memoria e poi essere già stato riavviato; in questo caso docker ps -a lo mostra come Up con un uptime insolitamente breve (Exited (137) compare soltanto se lo controlli mentre è fermo). In alternativa, l'host potrebbe usare la swap: in questo caso tutti i container sono ancora in esecuzione e l'intero sistema è semplicemente molto lento. vmstat 1 5 distingue i due casi: valori diversi da zero mantenuti nelle colonne si e so indicano l'uso della swap. In entrambi i casi, riduci la concorrenza dei job per la generazione delle miniature, il rilevamento dei volti e la ricerca intelligente.

Che cosa significa il codice di uscita 137 nei log di Immich?

137 è 128 più il segnale 9, quindi il processo è stato terminato con SIGKILL. Su un server Immich, di solito indica il raggiungimento di un limite di memoria, imposto dal container oppure causato dall'esaurimento della memoria dell'host. Tuttavia, il codice da solo non lo dimostra: Docker invia SIGKILL anche quando un container non si arresta entro il timeout previsto, che su Linux è di 10 secondi per impostazione predefinita. Controlla con docker inspect immich_machine_learning | grep -i oomkilled. Un valore true conferma che il kernel lo ha terminato per mancanza di memoria; free -m e sudo dmesg -T | grep -i oom-kill indicano poi se il problema riguardava il limite del container o l'intero host. Il container di machine learning è la vittima più comune, perché normalmente contiene il processo più grande.

Quanto spazio su disco richiede Immich per ogni foto?

Considera il file originale più un margine del 10-20%. Immich documenta che le miniature generate e i video transcodificati aumentano in media le dimensioni della libreria del 10-20%; inoltre, anche per una libreria molto grande, il database occupa in genere da 1 a 3 GB. Sono i video a determinare realmente lo spazio totale. Prima di scegliere un piano, misura quindi la dimensione media dei tuoi file invece di applicare un moltiplicatore al numero di foto.

Serve una GPU per Immich?

No. Tutte le componenti di Immich possono funzionare sulla CPU. Una scheda grafica accelera l'inferenza dei modelli nel container di machine learning e la codifica video, ma nessuna delle due è necessaria. La maggior parte dei piani VPS non offre una GPU. Su hardware con sola CPU, imposta i thread di transcodifica su 1 o 2, usa il modello dei volti buffalo_s e lascia che la prima importazione massiva venga eseguita durante la notte.