Perché Immich restituisce errori intermittenti durante le importazioni di grandi librerie mobili?
Gli errori intermittenti di Immich durante una grande importazione da dispositivo mobile di solito indicano che un livello sta cedendo sotto carico concorrente, non che l’intera libreria o tutti gli elementi caricati siano danneggiati.
Le importazioni di grandi dimensioni combinano il comportamento in background del dispositivo mobile, richieste lunghe, limiti del reverse proxy o del tunnel, scritture sul database, I/O dello spazio di archiviazione, elaborazione di miniature e video e code di apprendimento automatico. Per prima cosa raccogli un piccolo gruppo di elementi non riusciti e i relativi timestamp. Poi determina se il problema inizia sul telefono, nel percorso di rete, sul server applicativo o in una dipendenza sovraccarica.
Classifica il gruppo di errori prima di riprovare con tutto
Raggruppa gli errori in base al tipo di contenuto multimediale, alle dimensioni del file, al dispositivo sorgente, al percorso di rete e all’orario. Se falliscono solo i video di grandi dimensioni, verifica la durata delle richieste e i limiti di caricamento prima della CPU. Se foto e video casuali falliscono negli stessi intervalli di maggiore attività, le risorse condivise del server o l’instabilità della rete diventano ipotesi più probabili.
Una segnalazione del 2026 di un utente di Immich che descrive molti errori di caricamento da dispositivo mobile è utile perché mostra come una grande coda di elementi sul telefono possa far emergere errori ripetuti che richiedono una diagnosi per elemento e per percorso. Non dimostra l’esistenza di un unico problema universale del client mobile.
Non selezionare “ripeti tutto” come prima azione diagnostica. Salva i nomi o gli ID di dieci elementi non riusciti, un elemento di controllo caricato correttamente e le relative finestre dei log del client e del server. Un piccolo gruppo noto consente di verificare le modifiche senza generare una nuova ondata che nasconda le prove originali.
Confronta i caricamenti locali con il normale percorso remoto
Carica gli stessi file di test, piccoli e grandi, tramite una rete Wi-Fi locale stabile direttamente sull’endpoint locale attendibile, quindi ripeti usando il normale hostname remoto, la VPN, il tunnel o il reverse proxy. Mantieni invariati account ed elemento, così la variabile principale sarà il percorso.
Una segnalazione relativa a errori durante il backup di file di grandi dimensioni evidenzia perché i limiti delle richieste del proxy o del tunnel rientrino in questa verifica. Il servizio e le soglie riportati dipendono dalla configurazione; il test generale consiste nel verificare se il trasferimento locale diretto riesce mentre il percorso remoto fallisce costantemente.
Se entrambi i percorsi falliscono sugli stessi elementi, segui le prove relative al server e allo spazio di archiviazione. Se fallisce solo il percorso remoto, controlla le dimensioni massime del corpo della richiesta, il buffering delle richieste, i timeout di inattività e lettura, la terminazione TLS, i cambi di rete mobile e le ritrasmissioni. Modificare la concorrenza delle miniature non risolverà una richiesta che non raggiunge completamente Immich.
Correla gli errori con la crescita delle code e la pressione sulle risorse
Le importazioni di grandi dimensioni possono continuare ad accettare caricamenti mentre i processi in background si accumulano. Durante la finestra degli errori, osserva CPU, pressione sulla memoria, latenza dell’I/O a blocchi, reattività del database, riavvii dei container e completamento dei processi. Un’elevata utilizzazione da sola non è una prova; la metrica deve cambiare nello stesso momento degli errori.
L’articolo di Docker sul monitoraggio delle risorse relativo alle metriche di CPU, memoria, rete e disco dei container mostra il valore del confronto tra container invece di considerare una sola media dell’interhost. Su Linux, combina le metriche dei container con le prove relative allo spazio di archiviazione dell’host e alla pressione sulla memoria per gli stessi timestamp.
Se la pressione sulla memoria causa l’arresto dei container, la latenza dello spazio di archiviazione aumenta insieme agli errori di caricamento o il tempo di risposta del database aumenta mentre la coda smette di avanzare, riduci solo il carico di lavoro o la concorrenza responsabile e ripeti il test con lo stesso gruppo di elementi. Se i grafici delle risorse rimangono stabili, continua con i log dell’applicazione e la diagnosi del percorso di rete.
Considera il tasso di errore e la latenza di coda come segnali del carico
Un sistema può sembrare sano in base al tempo medio di risposta mentre una piccola percentuale di richieste va in timeout durante i picchi. Registra il numero di caricamenti tentati, gli errori, il tempo di risposta mediano e le richieste più lente durante una finestra controllata. In questo modo “intermittente” diventa misurabile anziché aneddotico.
Il framework di test del carico per l’analisi di errori e latenza raccomanda di analizzare le classi di stato, i problemi di connessione, le distribuzioni e le correlazioni nelle serie temporali. Non è necessario sottoporre la libreria familiare a uno stress aggressivo; usa la stessa struttura analitica sul tasso di importazione reale.
Se ridurre nettamente il tasso di arrivo diminuisce gli errori mentre ogni singolo elemento viene caricato correttamente, lo stack attuale non dispone di margine sufficiente per quell’intensità di importazione. Se gli stessi file falliscono anche uno alla volta, il problema è specifico dell’elemento o del percorso, oppure è un errore software deterministico, non una saturazione generica.
Riduci una sola fonte di pressione e ripeti il test con lo stesso schema di importazione
Scegli la modifica più sicura prevista dalle prove: riduci una sola concorrenza in background, metti in pausa un altro container pesante, usa il percorso locale, esegui l’importazione al di fuori della finestra di backup o correggi il timeout del proxy. Non modificare contemporaneamente limiti della CPU, spazio di archiviazione, regole del proxy e versioni dell’applicazione.
La procedura di ZimaSpace per le interruzioni del backup delle foto del telefono fornisce il percorso relativo al dispositivo mobile: la pianificazione in background, gli originali disponibili solo nel cloud e il cambiamento delle condizioni di rete possono interrompere i caricamenti anche quando il server funziona correttamente.
Il test è superato quando il gruppo di elementi scelto viene caricato correttamente e la stessa importazione più grande procede con un tasso di errore stabile, code in avanzamento e prestazioni interattive accettabili. Procedi con un’escalation quando gli errori persistono a basso carico o si ripetono sugli stessi elementi; includi i log del client, i log del server, lo stato del proxy, i grafici delle risorse, il tipo e le dimensioni del file e la prima richiesta non riuscita.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...
Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...
Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...
