Perché il lavoro in background di Immich aumenta improvvisamente dopo una modifica alla libreria?
Le attività in background di Immich possono aumentare bruscamente dopo una modifica a una libreria, perché un singolo evento del filesystem o della libreria può diramarsi in attività di scansione, metadati, derivati e indicizzazione.
La distinzione importante è tra un’ondata limitata di rielaborazioni previste e attività che rivisitano ripetutamente gli asset senza una modifica corrispondente. Lo spostamento di una cartella, una nuova scansione di una libreria esterna, file appena individuati o comportamenti specifici della versione possono produrre grafici simili per CPU e code; per questo l’evento della libreria deve essere collegato alle attività esatte che ha creato.
Una scansione della libreria è una fase di individuazione, non l’intero carico di lavoro
Una scansione riconcilia innanzitutto ciò che Immich può vedere sul disco con ciò che già conosce della libreria. L’individuazione di un asset nuovo o modificato può quindi rendere obsoleti o mancanti gli output successivi, creando ulteriore lavoro dopo che la scansione stessa sembra essere terminata.
Un rapporto di un utente su scansioni sovrapposte della libreria descrive una coda di scansione completata mentre le code di miniature, riconoscimento facciale e altre attività rimanevano molto popolate. Il meccanismo utile da comprendere è la diramazione: una breve fase di individuazione può creare una coda di elaborazione molto più lunga.
Leggi le code nell’ordine delle dipendenze. Se la coda della libreria scende a zero mentre le code per le attività derivate continuano ad avanzare, il server potrebbe semplicemente stare consumando attività prodotte dalla scansione completata. Definire l’intero periodo come una scansione ripetuta nasconde quale fase stia effettivamente utilizzando le risorse.
Le modifiche ai percorsi possono sembrare attività per nuovi asset
Le librerie esterne sono particolarmente sensibili all’identità del filesystem e alle modifiche dei percorsi. Quando i file vengono riorganizzati, l’applicazione potrebbe dover riconciliare le nuove posizioni con lo stato degli asset memorizzato. A seconda del comportamento della versione e del tipo di libreria, ciò può attivare più lavoro di quanto suggerisca il numero di foto realmente nuove.
Una discussione del 2026 sui file esterni spostati documenta un caso in cui i percorsi riorganizzati sono stati trattati come nuovi asset, causando nuovamente la generazione di miniature, l’analisi ML e l’elaborazione dei video. Si tratta della segnalazione di una limitazione nota, non della garanzia che ogni spostamento di cartella si comporti allo stesso modo.
Questo spiega perché una riorganizzazione della libreria può essere molto più costosa dell’aggiunta dello stesso numero di foto nuove. Se tuttavia i percorsi e i contenuti dei file non sono cambiati, una rigenerazione completa ripetuta indica una condizione diversa e dovrebbe essere analizzata, invece di essere accettata come normale attività in background.
Le code successive possono crescere mentre l’elaborazione procede
Il numero di elementi in attesa non deve necessariamente diminuire in modo monotono. Quando un’attività termina, può rendere un asset idoneo per un’altra attività o aggiungere ulteriori compiti a una fase successiva. Durante una riconciliazione di grandi dimensioni, quindi, il server può mostrare contemporaneamente un avanzamento attivo e una coda successiva in crescita.
La discussione su un arretrato di miniature osserva che possono comparire nuove attività per le miniature mentre vengono completate altre elaborazioni. Illustra inoltre un limite utile: bug storici e percorsi di importazione configurati male possono creare cicli patologici, quindi una coda in crescita deve essere interpretata tenendo conto della versione e dei percorsi.
Usa i contatori delle attività completate e controlla a campione gli output recenti, non solo il numero di elementi in attesa. Se compaiono miniature, i completamenti aumentano e alla fine il ritmo supera quello dei nuovi arrivi, la coda si sta svuotando, anche se il suo picco si verifica dopo la fine della scansione iniziale della libreria.
Un picco è anomalo quando l’attività non corrisponde ad alcuna modifica
Un carico in background previsto dovrebbe essere riconducibile a un evento definito: nuovi asset, un aggiornamento dei metadati, una modifica del percorso, una modifica del modello o un’azione esplicita di rigenerazione. La spiegazione è meno convincente quando gli stessi asset esistenti vengono pianificati ripetutamente senza modifiche alla configurazione o al contenuto.
Un rapporto recente in cui una scansione ha interessato altre librerie sembrava rigenerare attività in più librerie esterne e mostra perché l’ambito sia importante. Considera rapporti di questo tipo come prove legate a una specifica versione, da confrontare con i tuoi log, non come comportamento di base di Immich.
Il meccanismo smette inoltre di spiegare un host che rimane occupato molto tempo dopo che le code pertinenti si sono svuotate. In quel caso, controlla la manutenzione del database, i backup, un altro container, l’attività del filesystem o un processo bloccato. Una modifica alla libreria non dovrebbe diventare una spiegazione generica per un carico prolungato e non correlato.
Collega la modifica a una mappa delle attività prima e dopo
Prima di una modifica controllata alla libreria, registra il numero di asset, i conteggi delle attività principali in attesa e attive, l’uso della CPU, la latenza dello storage e l’orario dell’ultima scansione completata. Aggiungi o sposta un piccolo gruppo noto, ripeti la stessa osservazione e annota esattamente quali code crescono e con quale velocità si svuotano.
Usa la spiegazione di ZimaSpace sul percorso dei dati di Immich per assegnare ogni picco all’individuazione, all’elaborazione, al database o allo storage, invece di trattare tutte le attività in background come un’unica categoria.
Accetta il picco quando il lavoro generato è proporzionato alla modifica controllata, gli output compaiono, gli errori rimangono limitati e le code tornano verso i livelli normali. Escala il problema quando gli asset invariati vengono rigenerati ripetutamente, l’ambito supera la libreria modificata o le stesse attività falliscono senza alcun progresso.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
I modelli open stanno raggiungendo l’IA all’avanguardia: il 2026 sarà l’anno in cui l’IA locale diventerà abbastanza valida?
I modelli open stanno diventando abbastanza validi per un numero crescente di carichi di lavoro di IA locali, mentre i modelli cloud di frontiera...
NVIDIA PAIR trasforma la tua rete domestica in un cluster AI locale: ti serve ancora un unico grande server con GPU?
NVIDIA PAIR distribuisce le richieste di IA locale su più PC, rendendo la potenza di calcolo più elastica, mentre un server domestico può mantenere...
Perché Immich sembra più veloce sulla LAN rispetto alle connessioni remote?
Le richieste sulla LAN seguono generalmente un percorso più breve e con una latenza inferiore. L’accesso remoto introduce i limiti di capacità della WAN...
