Perché l’archiviazione delle miniature e del machine learning di Immich cresce durante le grandi importazioni da dispositivi mobili?

Le importazioni di grandi dimensioni di solito aumentano lo spazio occupato da Immich perché ogni risorsa genera derivati e record nel database, mentre i modelli scaricati occupano una cache separata.

Una famiglia trasferisce anni di foto dal telefono a un NAS domestico, poi vede lo spazio libero continuare a diminuire dopo che il contatore del caricamento ha raggiunto la fine. Questo può riflettere una normale elaborazione in background, anziché un’altra copia di ogni originale. La distinzione utile è tra file generati per ogni risorsa, file di modello condivisi e crescita che continua senza un corrispondente aumento del lavoro completato.

Un caricamento crea diversi tipi di stato

L’originale caricato è solo una parte della libreria risultante. Immich prepara anche rappresentazioni più piccole per la navigazione e memorizza le informazioni che collegano la risorsa al proprietario, alle date, agli album e alle funzioni di ricerca. Questi output servono richieste diverse, quindi il completamento del trasferimento di rete non significa che tutte le scritture successive siano già terminate.

La distinzione tra file multimediali e record del database è importante: i metadati dell’applicazione e gli embedding di ricerca risiedono in PostgreSQL, anziché essere fotografie aggiuntive a piena risoluzione. Il servizio di machine learning calcola risultati utilizzati dall’applicazione. Considerare tutti i byte aggiuntivi come originali duplicati porta quindi a una spiegazione errata della normale crescita durante l’importazione.

Si pensi a un telefono che ha terminato il trasferimento mentre il server sta ancora elaborando il lotto accettato. Gli originali potrebbero essere già stabili sul disco, ma le anteprime e i record ricercabili possono continuare a comparire. Confrontare le misurazioni dello spazio nella stessa fase di elaborazione; un gruppo appena caricato e uno completamente elaborato non sono campioni equivalenti.

Il numero di risorse spiega più dei gigabyte degli originali

Per pianificare lo spazio delle miniature, il numero e il tipo di risorse spesso spiegano più dei gigabyte complessivi degli originali. Mille fotografie di piccole dimensioni e una manciata di video lunghi possono occupare una capacità sorgente simile, ma richiedere numeri molto diversi di derivati delle immagini. Anche le dimensioni delle anteprime, le impostazioni di compressione e il contenuto delle immagini modificano ulteriormente i byte generati.

Le misurazioni delle miniature pubblicate illustrano questa variazione: un proprietario ha riferito 6,3 GB per una libreria da 70 GB, mentre un altro ha riferito circa 370 GB per 2 TB di foto e video. Si tratta di configurazioni individuali, non di benchmark controllati comparabili. Dimostrano perché adottare una singola percentuale presa da un forum può rappresentare in modo errato un’altra famiglia.

Come calcolo illustrativo, 100.000 risorse con una media di 250 KB di derivati delle immagini misurati richiedono circa 25 GB in unità decimali. Con 500 KB ciascuna, lo stesso numero richiede circa 50 GB. Nessuna delle due cifre include gli originali, i video codificati, la crescita del database o i backup; l’esempio isola il rapporto per risorsa, anziché raccomandare una riserva universale.

I file dei modelli e i record di ricerca crescono in modo diverso

La cache dei modelli contiene file di modello riutilizzabili, mentre i vettori di ricerca rappresentano singole risorse. Con un insieme fisso di modelli scaricati, l’aggiunta di altre foto non richiede il download di un nuovo modello completo per ogni immagine. L’aggiunta o la modifica dei modelli può invece aumentare lo spazio della cache per incrementi, indipendentemente dal numero di fotografie caricate.

Una distribuzione portatile reale mantiene la libreria, la cache dei modelli e i dati PostgreSQL in directory persistenti separate. Questa separazione rende osservabile ogni funzione dello spazio senza presumere che una singola dimensione Docker combinata rappresenti l’output del machine learning. È un esempio di disposizione tratto da una versione precedente, non una procedura d’installazione attuale né un insieme consigliato di tag dei container.

Distinguere anche l’utilizzo del disco dalla memoria caricata. Un modello può rimanere sul disco mentre la sua copia in memoria viene scaricata, e la cache del filesystem può aumentare la memoria segnalata senza creare altri file persistenti. Per spiegare un aumento improvviso, identificare la directory proprietaria e l’impostazione modificata prima di trarre conclusioni dal nome di un container.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Quando la crescita normale non è più una spiegazione

La normale crescita dei derivati ha un input limitato: un gruppo fisso di originali elaborato con impostazioni fisse. Non dovrebbe creare una popolazione in continua espansione di nuove risorse sorgente. Se il numero di risorse continua ad aumentare dopo l’interruzione di tutte le importazioni previste, la spiegazione deve includere percorsi di rilevamento, acquisizioni ripetute o un’altra fonte di nuovo lavoro.

Un caso confermato di scansione ricorsiva includeva la posizione di caricamento di Immich all’interno di una libreria esterna. Le miniature generate venivano quindi trattate come nuove immagini, creando altri derivati dei derivati. Si tratta di un meccanismo causale diverso da un’importazione mobile di grandi dimensioni e non deve essere usato come prova che ogni libreria voluminosa si moltiplichi naturalmente senza limiti.

Una crescita insolita nel livello scrivibile del container è un’altra categoria separata. Un rapporto del 2026 descriveva l’accumulo di centinaia di gigabyte; la discussione non ha stabilito una causa principale universale. Non eliminare file del database, contenuti multimediali o componenti interni di Docker per far apparire normale un grafico. Stabilire prima quale funzione sta crescendo e se il lavoro completato la spiega.

Misurare l’importazione per funzione di archiviazione

Registrare il numero e i byte delle risorse originali, i byte delle miniature e delle anteprime, i byte dei video codificati, le dimensioni del database e della cache dei modelli, nonché qualsiasi crescita temporanea o dei log prima di un’importazione rappresentativa. Ripetere la misurazione dopo che lo stesso gruppo ha completato i processi abilitati. Mantenere invariate le impostazioni dei contenuti multimediali, così le differenze possono essere attribuite all’importazione anziché a una modifica simultanea della configurazione.

La contabilizzazione dello spazio non sostituisce un piano di backup familiare. Un servizio fotografico utilizzabile richiede originali protetti e lo stato dell’applicazione necessario per ricostruire la libreria; una semplice directory delle miniature non può preservare la raccolta della famiglia. Mantenere separata questa attività di protezione dalla misurazione dell’overhead rigenerabile, così un esperimento per risparmiare spazio non possa diventare l’unica copia di un ricordo.

Accettare il risultato quando i totali misurati per funzione spiegano i byte aggiunti e non continuano a comparire risorse sorgente impreviste. Analizzare un meccanismo diverso quando l’inventario dei modelli non cambia ma persistono la crescita della cache o del livello scrivibile, oppure quando i file derivati rientrano nel rilevamento. Questo test risponde al motivo per cui lo spazio è cresciuto senza trasformare la spiegazione in una procedura di pulizia distruttiva.