Come ottimizzare le connessioni al database di Immich per container simultanei
Ottimizza le connessioni al database di Immich misurando la domanda totale di sessioni tra ogni processo Immich e gli altri client PostgreSQL, anziché aumentare subito max_connections. Il database deve disporre di sessioni sufficienti per il carico di lavoro reale, oltre a un margine per l’amministrazione, ma una concorrenza eccessiva può aumentare l’uso della memoria e la contesa senza rendere più veloci le query.
Su un server domestico con più container, registra insieme le connessioni attive, inattive e in attesa, oltre alla latenza delle query, all’uso di CPU e memoria e alla latenza dello storage, durante l’uso normale e durante l’avvio simultaneo. Un errore “troppi client” può derivare dalla configurazione aggregata, da un altro servizio o da una raffica di riavvii, anche quando un singolo container Immich sembra avere un carico modesto.
Inventaria ogni client PostgreSQL prima di modificare i limiti
Elenca ogni processo o replica del server Immich, attività di migrazione o manutenzione, processo di backup, strumento di monitoraggio e applicazione indipendente che si connette alla stessa istanza PostgreSQL. Quando possibile, assegna loro utenti database distinti, in modo che pg_stat_activity possa mostrare chi mantiene le sessioni. Registra il valore attuale di max_connections e conserva un percorso amministrativo per la risposta agli incidenti.
Una discussione sugli “troppi client” di Immich include un commento del progetto secondo cui, in quella versione, Immich utilizzava un pool predefinito di 10 connessioni. Una discussione separata del 2026 osserva che più worker Immich possono mantenere ciascuno un pool. Considera questi valori come dettagli implementativi specifici della versione, non come numeri da moltiplicare ciecamente nelle versioni future. Se il database è già vicino al limite di connessioni mentre Immich è inattivo, identifica il proprietario di quelle sessioni prima di ottimizzare Immich. Se le sessioni attive sono poche ma le query sono lente, il numero di connessioni potrebbe essere un sintomo della latenza dello storage o delle query, anziché il collo di bottiglia principale.
Crea un budget delle connessioni basato sulla concorrenza misurata
Riserva sessioni per l’amministrazione del database, gli strumenti di backup e ripristino, le migrazioni e il monitoraggio.
Poi assegna le connessioni applicative rimanenti tra il numero di processi Immich eseguiti contemporaneamente e le altre applicazioni. L’obiettivo è un pool abbastanza grande da evitare attese inutili durante il lavoro normale, ma non più grande di quanto il database possa gestire in modo efficiente.
Un’analisi del dimensionamento dei pool di connessioni PostgreSQL descrive il pool ideale come abbastanza grande da soddisfare la domanda normale, ma il più piccolo possibile, perché un numero inferiore di sessioni backend riduce la contesa. Applica questo principio alla domanda osservata di Immich, invece di copiare le dimensioni di un pool per server web progettato per un altro carico di lavoro.
Se la versione di Immich non espone un controllo supportato per le dimensioni del pool, non modificare gli interni solo per raggiungere un numero obiettivo. Controlla ciò che puoi: il numero di repliche applicative, i client indipendenti, la tempistica dei riavvii, la sovrapposizione dei backup e la capacità del database. Rivaluta la configurazione supportata quando cambiano le versioni.
Riduci il ricambio delle connessioni e le attese del database prima di aggiungere altre sessioni
Scagliona l’avvio dei container, in modo che Immich, gli strumenti di analisi, i processi di backup e le altre applicazioni non si riconnettano o eseguano migrazioni tutti contemporaneamente. Usa controlli di salute e disponibilità che attendano che PostgreSQL sia utilizzabile, ma evita cicli di tentativi troppo ravvicinati, che possono creare una raffica di connessioni mentre il database è ancora in fase di ripristino.
La guida di ZimaSpace sulla sicurezza di un database esterno per Immich definisce un limite importante: quando PostgreSQL viene separato dallo stack predefinito, diventano esplicite le responsabilità relative a versione, estensioni, privilegi, backup e rollback. Un proxy per le connessioni o un host database aggiuntivo non dovrebbe essere introdotto soltanto per nascondere query lente o uno storage sovraccarico.
Se molte sessioni sono inattive e il numero elevato di applicazioni è legittimo, un pooler per le connessioni può ridurre le sessioni backend in alcune architetture PostgreSQL, ma solo dopo aver testato la versione esatta di Immich, le migrazioni, la semantica delle transazioni e il comportamento delle istruzioni preparate. Il pooling non sostituisce la correzione di un client fuori controllo o di un database sovraccarico.
Convalida con caricamenti, ricerche, attività e riavvii simultanei
Crea un picco ripetibile: esegui caricamenti rappresentativi da dispositivi mobili, una ricerca o consultazione di contenuti meno recenti e il normale insieme di attività in background, mentre gli altri container previsti sono attivi. Registra il numero di connessioni per utente e stato, gli errori di acquisizione o di richiesta, la latenza delle query, l’uso di CPU e memoria del database e la latenza del disco. Poi ripeti dopo una sola modifica.
Una configurazione superata mantiene le sessioni al di sotto della soglia di errore con un margine amministrativo, evita gli errori “troppi client”, mantiene la latenza delle query entro l’obiettivo domestico e consente alle code di svuotarsi dopo il picco. Più connessioni sono giustificate solo quando le richieste attendono realmente una sessione mentre il database dispone ancora di capacità di CPU, memoria e I/O.
Riavvia lo stack applicativo e poi l’host una volta, per testare il picco massimo di connessioni. Se l’errore compare solo durante l’avvio, correggi l’ordine di avvio o il comportamento dei tentativi, invece di aumentare il limite permanente. Se le sessioni si accumulano nel tempo, acquisisci gli utenti e le query proprietari e segnala il modello di perdita includendo le versioni e le prove sullo stato delle connessioni.
Prodotti consigliati
Supporto e consigli
Altro da leggere
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...
Perché Immich ricrea i file mancanti con il proprietario sbagliato?
Immich non dovrebbe ricreare silenziosamente gli originali mancanti. Identifica il tipo di file rigenerato e il programma che lo ha scritto, quindi correggi l’identità...
