Come ridurre il tempo di avvio di Immich dopo il riavvio

Se Immich diventa utilizzabile lentamente solo dopo il riavvio del server domestico, misura quale dipendenza diventa pronta per ultima prima di provare a “velocizzare” l’applicazione.

Un riavvio può fare in modo che i montaggi dello spazio di archiviazione, PostgreSQL, i percorsi di rete, il DNS o altri servizi siano disponibili in un ordine diverso rispetto a un normale riavvio di Immich. La metrica utile non è il momento in cui Docker segnala l’avvio di un container, ma il tempo trascorso dall’avvio dell’host fino a quando il database accetta richieste reali, lo spazio di archiviazione richiesto è montato, Immich smette di riprovare a connettersi alle dipendenze e un client riesce a caricare la timeline. Acquisisci questa sequenza una volta, quindi elimina l’attesa o il ciclo di tentativi effettivo.

Misura la sequenza di avvio prima di modificare qualsiasi cosa

Riavvia durante una finestra di manutenzione e registra l’orario di quattro momenti: host raggiungibile, spazio di archiviazione relativo a Immich montato, database in buono stato e Immich utilizzabile da un client. Acquisisci anche gli orari di avvio dei container, gli stati di integrità, il numero di riavvii e la prima riga di log utile di ogni servizio. In questo modo, “l’avvio sembra lento” diventa un ritardo circoscritto.

Confronta il risultato con un normale riavvio dello stack eseguito dopo che l’host è già completamente operativo. Se Immich si riavvia rapidamente in seguito ma è lento solo all’avvio, il collo di bottiglia è probabilmente un problema di ordine o una dipendenza dalla disponibilità esterna all’applicazione. Se entrambi i casi sono altrettanto lenti, esamina invece il lavoro del database, la latenza dello spazio di archiviazione, le migrazioni o la pressione sulla CPU.

Non ottimizzare tutti i livelli contemporaneamente. L’uscita da questa fase consiste nell’identificare il primo componente la cui disponibilità è in ritardo rispetto all’avvio del container o che costringe ripetutamente Immich a riprovare.

Verifica che lo spazio di archiviazione sia pronto prima dell’avvio di Immich

Verifica che ogni montaggio bind e ogni percorso basato sulla rete esista e contenga i dati attesi prima dell’avvio dei servizi Immich. Un punto di montaggio può esistere come directory locale vuota mentre il disco reale o la condivisione NAS non è ancora disponibile; ciò può far avviare l’applicazione utilizzando la vista del filesystem sbagliata.

Se il database o i contenuti multimediali risiedono su uno spazio di archiviazione che diventa disponibile tardi durante l’avvio, fai dipendere il servizio da quel montaggio a livello dell’host oppure rimanda l’avvio dello stack finché il montaggio non è verificabilmente presente. Il test dovrebbe controllare il filesystem effettivamente montato o un indicatore noto, non soltanto l’esistenza del nome della directory.

Dopo aver modificato la disponibilità dello spazio di archiviazione, riavvia di nuovo e confronta gli stessi orari. Una modifica riuscita elimina i tentativi ripetuti o il comportamento relativo a percorsi vuoti senza modificare la configurazione di Immich a regime. Se lo spazio di archiviazione era già pronto molto prima del database, passa alla sequenza delle dipendenze invece di aggiungere timer di attesa arbitrari.

Attendi che il database sia in buono stato, non semplicemente in esecuzione

PostgreSQL può avere un container in esecuzione prima di essere pronto ad accettare il carico di lavoro dell’applicazione, soprattutto dopo un arresto anomalo, un ritardo dello spazio di archiviazione, l’inizializzazione o un ripristino. Confronta il passaggio del database allo stato integro con i primi errori di connessione di Immich nei log di avvio.

Un semplice ordine di avvio può avviare un container dipendente prima che il servizio necessario sia effettivamente pronto. Quando la versione di Compose e le definizioni dei servizi lo supportano, i controlli delle dipendenze basati sull’integrità possono distinguere tra “container avviato” e “dipendenza pronta”. Usali per eliminare i cicli di riconnessione evitabili, invece di nascondere una dipendenza lenta o non integra.

Mantieni il controllo di disponibilità circoscritto e significativo. Un controllo del database dovrebbe dimostrare che può accettare la connessione necessaria a Immich; non dovrebbe eseguire una query costosa che aggiunge a sua volta un ritardo. Quando la disponibilità del database precede costantemente l’avvio di Immich, ripeti il test di riavvio dell’host prima di modificare altro.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separa i cicli di tentativi dal normale lavoro di avvio

Se lo spazio di archiviazione e PostgreSQL sono pronti ma Immich impiega ancora molto più tempo dopo un riavvio, esamina i log dell’applicazione e dei worker alla ricerca di errori di connessione ripetuti, controlli di integrità falliti, migrazioni, inizializzazione dei processi o pressione sulle risorse. Errori ripetuti a intervalli fissi indicano spesso un’attesa; un’attività prolungata della CPU o del disco con avanzamento indica invece un reale lavoro di avvio.

L’ordine delle dipendenze funziona meglio se abbinato a controlli di integrità significativi, anziché a brevi ritardi fissi. Un modello di controllo dell’integrità in Compose può aiutare a impedire che un’applicazione entri in competizione con un database o una cache ancora in fase di inizializzazione. Mantieni realistici i controlli; ridurre gli intervalli finché un servizio malato non appare integro non migliora l’avvio.

Se il numero di riavvii aumenta durante l’avvio, interrompi la raffica e identifica la prima dipendenza non disponibile prima di regolare CPU, memoria o i parametri di avvio dell’immagine. Un controllo delle dipendenze nei cicli di riavvio dei container aiuta a distinguere un prerequisito lento da un problema interno a Immich.

Riavvia di nuovo e verifica il tempo necessario per una reale utilizzabilità

Dopo una modifica mirata, esegui un riavvio completo dell’host e registra gli stessi orari. Un miglioramento reale dovrebbe ridurre l’intervallo tra la disponibilità delle dipendenze e un client Immich utilizzabile, senza introdurre nuovi cicli di riavvio, montaggi mancanti o errori in background.

Non limitarti a testare la pagina di accesso web. Apri diverse foto meno recenti, esegui una ricerca, carica un video rappresentativo, verifica che un client mobile si connetta e carica un contenuto eliminabile per esercitare sia i percorsi di lettura sia quelli di scrittura. Per le normali esigenze domestiche, il server non è “avviato” finché queste operazioni non funzionano.

Esegui un secondo riavvio dopo il primo test riuscito per assicurarti che il risultato non dipenda dalla fortuna della cache o da un evento occasionale di temporizzazione della rete. Se l’avvio rimane incoerente, conserva le tracce di avvio e concentrati sul componente la cui disponibilità varia tra un’esecuzione e l’altra. Non nascondere la variabilità con un ritardo fisso più lungo, a meno che non esista un segnale di disponibilità migliore.