Perché Immich provoca un’attività ripetuta del disco durante la notte?
Immich può generare un’attività ripetuta sui dischi durante la notte perché la manutenzione pianificata, le operazioni sul database, i processi multimediali in coda o i tentativi automatici continuano anche dopo che le persone smettono di usare la libreria.
Una casa tranquilla non significa che il server sia inattivo. La domanda utile è se lo stesso processo e lo stesso lavoro spieghino le letture o le scritture avvenute alla stessa ora. Prima correla l’attività, poi stabilisci se si tratta di lavoro previsto, recupero di arretrati o di un ciclo che dovrebbe essere interrotto.
Confronta il picco del disco con l’orario prima di modificare qualsiasi impostazione
Inizia con tre notti di rilevazioni degli orari anziché con una singola osservazione rumorosa. Registra quando aumenta l’I/O a blocchi, quale dispositivo è occupato, se prevalgono le letture o le scritture e se il fenomeno inizia quasi alla stessa ora. Un orario di inizio ripetibile fa pensare a un’attività pianificata; un andamento irregolare indica più probabilmente nuovi arrivi, tentativi automatici o un altro container.
Le installazioni di Immich possono pianificare backup del database e attività orientate all’integrità nelle ore di minore utilizzo, quindi un picco al mattino presto potrebbe essere intenzionale. Non disabilitare un’attività solo perché riattiva i dischi. Verifica prima se, dopo la finestra di attività, compare un backup corrispondente, un risultato di manutenzione o il completamento di una coda.
La diagnosi adiacente di ZimaSpace sul lavoro in background di Immich nelle ore di inattività usa la stessa regola degli orari: collega il sintomo visibile al processo e all’attività prima di considerare “inattivo” uno stato anomalo.
Separa le scritture di PostgreSQL dalle letture dei contenuti multimediali
Le modifiche allo stato dell’applicazione Immich possono mantenere attivo PostgreSQL anche quando non viene aperta alcuna nuova foto. I checkpoint del database, la registrazione write-ahead, le attività correlate al vacuum e i normali aggiornamenti dell’applicazione hanno una firma I/O diversa dalla scansione di migliaia di file multimediali. Identifica il percorso o il dispositivo che riceve il traffico prima di dare la colpa alla libreria fotografica.
La discussione sull’osservabilità di PostgreSQL in analisi di pg_stat_io spiega perché sia necessario separare letture, scritture, attività dei processi backend, comportamento del checkpointer e scritture in background. Usa questa distinzione per capire se il dispositivo del database è occupato perché transazioni utili vengono rese persistenti o perché qualcosa sta generando continuamente attività.
Se le scritture del database sono piccole e periodiche mentre i dischi dei contenuti multimediali restano inattivi, il comportamento potrebbe essere una normale attività di manutenzione del database. Se lo stesso file del database riceve scritture intense e prolungate mentre nessuna attività avanza, conserva i log e analizza le query responsabili o il ciclo di riavvio invece di spostare l’intera libreria su uno spazio di archiviazione più veloce.
Verifica che le code in background avanzino davvero
Apri la vista delle attività e confronta i processi in attesa, attivi, non riusciti e completati prima e dopo la finestra notturna. La generazione delle miniature, l’elaborazione dei video, l’estrazione dei metadati, le attività di apprendimento automatico o l’elaborazione di una libreria importata possono mantenere legittimamente attivo lo spazio di archiviazione dopo una modifica significativa. Una coda in diminuzione è un segno di recupero utile.
Un recente rapporto della community sulle letture continue senza una causa evidente mostra il limite diagnostico opposto: letture continue molto elevate senza attività prevista meritano un’indagine, anziché essere considerate semplicemente “ciò che fa Immich”. Considera la velocità riportata come un caso specifico, non come un valore di riferimento.
Se gli stessi pochi processi non riescono e rientrano nella coda, l’attività del disco può ripetersi senza produrre avanzamenti. Acquisisci il primo errore e un contenuto interessato, quindi isola il tipo di attività. Non svuotare tutte le code né rigenerare l’intera libreria prima di aver stabilito se il ciclo sia causato da un singolo file, dai permessi, dalla latenza dello spazio di archiviazione o da una dipendenza del servizio.
Attribuisci l’I/O a un processo invece di affidarti al rumore del disco
Usa il monitoraggio dell’I/O a livello dell’host durante la prossima ricorrenza per identificare il processo che sta leggendo o scrivendo sul dispositivo. Poi associa quel processo al server Immich, a PostgreSQL, all’apprendimento automatico, a uno strumento di backup, a un antivirus, a una verifica del filesystem o a un container estraneo. I LED delle unità e il rumore delle ventole non possono fornire queste informazioni sull’origine.
Un flusso di lavoro pratico con iotop dimostra il metodo incentrato sul processo. Registra diversi campioni perché un breve picco può scomparire tra un’osservazione e l’altra; l’obiettivo è rilevare il processo durante la stessa finestra temporale in cui compare il sintomo.
Se Immich non è il principale responsabile dell’I/O, smetti di modificare le impostazioni di Immich e segui il processo effettivamente coinvolto. Se il responsabile è PostgreSQL, Immich o un processo correlato, confronta i relativi log e l’avanzamento delle attività con il campione di I/O. In questo modo “il server è rumoroso ogni notte” diventa un componente e un’attivazione specifici.
Stabilisci il confine tra il normale lavoro notturno e un guasto
Considera l’attività normale quando inizia secondo una pianificazione nota o dopo una modifica recente alla libreria, completa un lavoro utile, non lascia un numero crescente di errori e riporta la latenza dello spazio di archiviazione e la profondità della coda ai valori normali. Registra la durata normale, così un eventuale aumento futuro avrà un punto di confronto.
Una discussione storica su Immich relativa alle scritture frequenti del database mostra perché possa esserci attività del database anche senza un’azione visibile dell’utente. Poiché versioni e installazioni cambiano, usa il caso solo per motivare una misurazione separata del database, non per dichiarare normali tutte le scritture persistenti.
Intervieni quando l’I/O continua dopo l’arresto delle code, gli stessi errori si ripetono, la latenza dello spazio di archiviazione influisce sull’uso diurno, lo spazio libero diminuisce inaspettatamente o il fenomeno aumenta notte dopo notte. Conserva gli orari, l’I/O dei processi, il numero di attività, i log pertinenti, lo spazio libero del filesystem e un’attivazione riproducibile prima di apportare modifiche invasive.
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...
