Så optimerar du Immich-databasanslutningar för samtidiga containrar

Optimera databasanslutningar för Immich genom att mäta den totala sessionsbelastningen från alla Immich-processer och andra PostgreSQL-klienter, i stället för att först höja max_connections. Databasen behöver tillräckligt många sessioner för den faktiska arbetsbelastningen samt administrativt utrymme, men överdriven samtidighet kan öka minnesanvändningen och konkurrensen utan att göra frågorna snabbare.

På en hemmaserver med flera containrar ska du registrera aktiva, inaktiva och väntande anslutningar tillsammans med frågelatens, CPU-, minnes- och lagringslatens under normal användning och vid samtidig uppstart. Ett ”för många klienter”-fel kan bero på den samlade konfigurationen, en annan tjänst eller en omstartsstorm, även när en enskild Immich-container verkar ha en måttlig belastning.

Inventera alla PostgreSQL-klienter innan du ändrar gränser

Lista varje Immich-serverprocess eller replik, migrerings- eller underhållsuppgift, säkerhetskopieringsjobb, övervakningsverktyg och orelaterad applikation som ansluter till samma PostgreSQL-instans. Ge dem separata databasanvändare när det är praktiskt, så att pg_stat_activity kan visa vem som håller sessionerna. Notera det aktuella värdet för max_connections och behåll en administrativ åtkomstväg för incidenthantering.

En diskussion om ”för många klienter” i Immich innehåller en projektkommentar om att Immich använde en standardpool på 10 i den versionen. En separat diskussion från 2026 beskriver att flera Immich-arbetare kan ha varsin pool. Betrakta dessa värden som versionsspecifik implementeringsinformation, inte som ett tal som utan eftertanke ska multipliceras för framtida versioner. Om databasen redan ligger nära anslutningsgränsen när Immich är inaktivt ska du identifiera ägarna till sessionerna innan du justerar Immich. Om det finns få aktiva sessioner men frågorna är långsamma kan antalet anslutningar vara ett symptom på lagrings- eller frågelatens snarare än den primära flaskhalsen.

Skapa en anslutningsbudget utifrån uppmätt samtidighet

Reservera sessioner för databasadministration, verktyg för säkerhetskopiering och återställning, migreringar samt övervakning.

Fördela sedan de återstående applikationsanslutningarna mellan antalet Immich-processer och andra applikationer som körs samtidigt. Målet är en pool som är tillräckligt stor för att normalt arbete inte ska behöva vänta i onödan, men inte större än vad databasen kan hantera effektivt.

En analys av dimensionering av anslutningspooler för PostgreSQL beskriver den ideala poolen som tillräckligt stor för normal efterfrågan men så liten som praktiskt möjligt, eftersom färre backend-sessioner minskar konkurrensen. Tillämpa den principen på Immichs observerade behov i stället för att kopiera en poolstorlek för webbservrar från en annan arbetsbelastning.

Om Immich-versionen inte erbjuder en stödd inställning för poolstorlek ska du inte ändra interna delar enbart för att nå ett visst antal. Styr i stället det du kan: antalet applikationsrepliker, orelaterade klienter, tidpunkten för omstarter, överlappning med säkerhetskopiering och databasens kapacitet. Utvärdera stödda konfigurationsalternativ på nytt när versionerna ändras.

Minska anslutningsväxling och väntan i databasen innan du lägger till fler sessioner

Sprid ut uppstarten av containrarna så att Immich, analysverktyg, säkerhetskopieringsjobb och andra appar inte alla ansluter på nytt eller migrerar samtidigt. Använd hälso- och beredskapskontroller som väntar tills PostgreSQL kan användas, men undvik täta försöksloopar som skapar en anslutningsstorm medan databasen fortfarande återhämtar sig.

Guiden från ZimaSpace om säker användning av extern Immich-databas markerar en viktig gräns: när PostgreSQL separeras från standardstacken blir ansvar för versioner, tillägg, behörigheter, säkerhetskopiering och återställning tydliga. En anslutningsproxy eller ytterligare databasserver ska inte införas enbart för att dölja långsamma frågor eller överbelastad lagring.

Om många sessioner är inaktiva och antalet applikationer faktiskt är högt kan en anslutningspoolare minska antalet backend-sessioner i vissa PostgreSQL-arkitekturer, men först efter testning av den exakta Immich-versionen, migreringarna, transaktionssemantiken och beteendet hos förberedda satser. Poolning ersätter inte korrigering av en klient som skapar okontrollerat många anslutningar eller en överbelastad databas.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Validera med samtidiga uppladdningar, sökningar, jobb och omstarter

Skapa en upprepningsbar toppbelastning: kör representativa mobiluppladdningar, en äldre sök- eller bläddringsåtgärd och den normala blandningen av bakgrundsjobb medan andra förväntade containrar är aktiva. Registrera antalet anslutningar per användare och tillstånd, fel vid anslutningsförvärv eller begäranden, frågelatens, databasens CPU- och minnesanvändning samt disklatens. Upprepa sedan testet efter en enda ändring.

En godkänd konfiguration håller sessionerna under felgränsen med administrativt utrymme, undviker fel av typen ”för många klienter”, håller frågelatensen inom hushållets mål och låter köerna tömmas efter toppbelastningen. Fler anslutningar är motiverade först när begäranden faktiskt väntar på en session samtidigt som databasen fortfarande har CPU-, minnes- och I/O-kapacitet.

Starta om applikationsstacken och därefter värden en gång för att testa den största anslutningstoppen. Om felet endast uppstår under uppstart ska du korrigera ordningsföljden och försöksbeteendet i stället för att höja den permanenta gränsen. Om sessioner ansamlas över tid ska du samla in vilka användare och frågor som äger dem och eskalera läckagemönstret tillsammans med versions- och anslutningstillstånd.