Hoe optimaliseer je Immich-databaseverbindingen voor gelijktijdige containers?

Optimaliseer databaseverbindingen van Immich door de totale sessiebehoefte van elk Immich-proces en elke andere PostgreSQL-client te meten, in plaats van eerst max_connections te verhogen. De database heeft voldoende sessies nodig voor de werkelijke werklast plus administratieve reserve, maar overmatige gelijktijdigheid kan het geheugengebruik en conflicten verhogen zonder query's sneller te maken.

Registreer op een thuisserver met meerdere containers actieve, inactieve en wachtende verbindingen, samen met querylatentie, CPU-, geheugen- en opslaglatentie tijdens normaal gebruik en tijdens gelijktijdig opstarten. Een foutmelding als “too many clients” kan worden veroorzaakt door een gezamenlijke configuratie, een andere service of een herstartgolf, zelfs wanneer één Immich-container bescheiden lijkt.

Breng elke PostgreSQL-client in kaart voordat je limieten wijzigt

Noteer elk Immich-serverproces of elke replica, migratie- of onderhoudstaak, back-uptaak, monitoringtool en niet-gerelateerde applicatie die verbinding maakt met dezelfde PostgreSQL-instantie. Geef ze waar praktisch afzonderlijke databasegebruikers, zodat pg_stat_activity kan laten zien wie sessies vasthoudt. Noteer de huidige waarde van max_connections en behoud één administratieve route voor incidentrespons.

Een Immich-discussie over “too many clients” bevat een projectopmerking dat Immich in die release een standaardpool van 10 gebruikte. Een afzonderlijke discussie uit 2026 vermeldt dat meerdere Immich-workers elk een pool kunnen onderhouden. Beschouw deze cijfers als versiegebonden implementatiecontext en niet als een getal dat je blindelings over toekomstige releases moet vermenigvuldigen. Als de database al bijna de verbindingslimiet heeft bereikt terwijl Immich inactief is, bepaal dan eerst wie die sessies beheert voordat je Immich afstemt. Als er weinig actieve sessies zijn maar query's traag zijn, kan het aantal verbindingen een symptoom zijn van opslag- of querylatentie in plaats van de primaire bottleneck.

Stel op basis van gemeten gelijktijdigheid een verbindingsbudget op

Reserveer sessies voor databasebeheer, back-up- en hersteltools, migraties en monitoring.

Verdeel vervolgens de resterende applicatieverbindingen over het aantal Immich-processen en andere applicaties dat gelijktijdig draait. Het doel is een pool die groot genoeg is zodat normaal werk niet onnodig hoeft te wachten, maar niet groter dan de database efficiënt kan uitvoeren.

Een analyse van de poolgrootte voor PostgreSQL-verbindingen beschrijft de ideale pool als groot genoeg voor de normale vraag en tegelijk zo klein als praktisch mogelijk, omdat minder backendsessies conflicten verminderen. Pas dat principe toe op de gemeten vraag van Immich in plaats van zonder meer de poolgrootte van een webserver voor een andere werklast over te nemen.

Als de Immich-release geen ondersteunde instelling voor de poolgrootte biedt, patch dan geen interne onderdelen alleen om een bepaald aantal te bereiken. Beheers wat je wel kunt beïnvloeden: het aantal applicatiereplica's, niet-gerelateerde clients, het tijdstip van herstarts, overlap met back-ups en de databasecapaciteit. Evalueer ondersteunde configuratie opnieuw wanneer versies veranderen.

Verminder verbindingswisselingen en wachten op de database voordat je meer sessies toevoegt

Laat containers gespreid opstarten, zodat Immich, analysetaken, back-uptaken en andere apps niet allemaal tegelijk opnieuw verbinding maken of migreren. Gebruik health- en readiness-controles die wachten totdat PostgreSQL bruikbaar is, maar vermijd krappe retry-lussen die een verbindingsgolf veroorzaken terwijl de database nog herstelt.

De ZimaSpace-gids over de veiligheid van een externe Immich-database markeert een belangrijke grens: zodra PostgreSQL van de standaardstack wordt gescheiden, worden verantwoordelijkheden rond versies, extensies, rechten, back-ups en terugdraaien expliciet. Introduceer geen verbindingsproxy of extra databasehost uitsluitend om trage query's of overbelaste opslag te verbergen.

Als veel sessies inactief zijn en het applicatieaantal terecht hoog is, kan een connection pooler in sommige PostgreSQL-architecturen het aantal backendsessies verminderen, maar alleen na het testen van de exacte Immich-versie, migraties, transactiesemantiek en het gedrag van prepared statements. Pooling is geen vervanging voor het corrigeren van een ontspoorde client of een overbelaste database.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valideer met gelijktijdige uploads, zoekopdrachten, taken en herstarts

Stel een herhaalbare piekbelasting samen: voer representatieve mobiele uploads uit, een oudere zoek- of bladeractie en de normale combinatie van achtergrondtaken, terwijl andere verwachte containers actief zijn. Registreer het aantal verbindingen per gebruiker en status, fouten bij het verkrijgen van verbindingen of tijdens verzoeken, querylatentie, CPU- en geheugengebruik van de database en schijflatentie. Herhaal dit vervolgens na één wijziging.

Een geslaagde configuratie houdt het aantal sessies onder de storingslimiet met administratieve reserve, voorkomt fouten als “too many clients”, houdt de querylatentie binnen de gewenste huishoudelijke doelwaarde en zorgt ervoor dat wachtrijen na de piek leeglopen. Meer verbindingen zijn alleen gerechtvaardigd wanneer verzoeken daadwerkelijk op een sessie wachten terwijl de database nog CPU-, geheugen- en I/O-capaciteit heeft.

Herstart eerst de applicatiestack en daarna eenmaal de host om de grootste verbindingspiek te testen. Als de fout alleen tijdens het opstarten optreedt, corrigeer dan de volgorde en het retry-gedrag in plaats van de permanente limiet te verhogen. Als sessies zich na verloop van tijd opstapelen, leg dan de bijbehorende gebruikers en query's vast en meld dat lekpatroon met versies en bewijs van de verbindingsstatus.