So optimieren Sie Immich-Datenbankverbindungen für gleichzeitig ausgeführte Container

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Optimize Immich Database Connections for Concurrent Containers - Zima Store Online

Optimieren Sie die Immich-Datenbankverbindungen, indem Sie den gesamten Sitzungsbedarf aller Immich-Prozesse und anderer PostgreSQL-Clients messen, anstatt zuerst max_connections zu erhöhen. Die Datenbank benötigt genügend Sitzungen für die tatsächliche Arbeitslast sowie administrative Reserven. Eine übermäßige Nebenläufigkeit kann jedoch den Speicherverbrauch und die Konkurrenz um Ressourcen erhöhen, ohne Abfragen zu beschleunigen.

Erfassen Sie auf einem Home-Server mit mehreren Containern während der normalen Nutzung und beim gleichzeitigen Start aktive, inaktive und wartende Verbindungen sowie Abfragelatenz, CPU-, Speicher- und Speicherlatenz. Ein Fehler wie „zu viele Clients“ kann durch eine aggregierte Konfiguration, einen anderen Dienst oder eine Neustart-Schleife verursacht werden, selbst wenn ein einzelner Immich-Container unauffällig wirkt.

Erfassen Sie alle PostgreSQL-Clients, bevor Sie Limits ändern

Listen Sie jeden Immich-Serverprozess bzw. jede Replik, jede Migrations- oder Wartungsaufgabe, jeden Backup-Auftrag, jedes Überwachungstool und jede unabhängige Anwendung auf, die eine Verbindung zu derselben PostgreSQL-Instanz herstellt. Verwenden Sie nach Möglichkeit separate Datenbankbenutzer, damit pg_stat_activity anzeigen kann, wer Sitzungen hält. Notieren Sie den aktuellen Wert von max_connections und halten Sie einen administrativen Zugangsweg für die Störungsbehebung frei.

Eine „Zu viele Clients“-Diskussion zu Immich enthält einen Projektkommentar, dem zufolge Immich in dieser Version standardmäßig einen Pool mit 10 Verbindungen verwendete. Eine separate Diskussion aus dem Jahr 2026 weist darauf hin, dass mehrere Immich-Worker jeweils einen eigenen Pool verwalten können. Betrachten Sie diese Angaben als versionsspezifischen Implementierungskontext und nicht als Zahl, die Sie für künftige Versionen unkritisch multiplizieren sollten. Wenn die Datenbank bereits im Leerlauf von Immich nahe an ihrem Verbindungslimit liegt, ermitteln Sie zunächst, wem diese Sitzungen gehören, bevor Sie Immich optimieren. Wenn nur wenige Sitzungen aktiv sind, Abfragen aber langsam bleiben, kann die Verbindungsanzahl eher ein Symptom von Speicher- oder Abfragelatenz als der eigentliche Engpass sein.

Erstellen Sie anhand der gemessenen Nebenläufigkeit ein Verbindungsbudget

Reservieren Sie Sitzungen für die Datenbankverwaltung, Backup- und Wiederherstellungswerkzeuge, Migrationen und die Überwachung.

Verteilen Sie anschließend die verbleibenden Anwendungsverbindungen auf die Anzahl der gleichzeitig laufenden Immich-Prozesse und anderen Anwendungen. Der Pool sollte groß genug sein, damit die normale Arbeit nicht unnötig wartet, aber nicht größer, als die Datenbank effizient verarbeiten kann.

Eine Analyse zur Dimensionierung von PostgreSQL-Verbindungspools beschreibt einen idealen Pool als groß genug für den normalen Bedarf und zugleich so klein wie praktisch möglich, da weniger Backend-Sitzungen die Konkurrenz um Ressourcen verringern. Wenden Sie dieses Prinzip auf den beobachteten Immich-Bedarf an, anstatt die Poolgröße eines Webservers aus einer anderen Arbeitslast zu übernehmen.

Wenn die Immich-Version keine unterstützte Einstellung für die Poolgröße bereitstellt, ändern Sie keine Interna allein, um eine bestimmte Anzahl zu erreichen. Steuern Sie, was Sie beeinflussen können: die Anzahl der Anwendungsreplikas, unabhängige Clients, das Timing von Neustarts, die Überschneidung mit Backups und die Datenbankkapazität. Überprüfen Sie die unterstützte Konfiguration erneut, wenn sich die Version ändert.

Verringern Sie Verbindungswechsel und Datenbankwartezeiten, bevor Sie weitere Sitzungen hinzufügen

Staffeln Sie den Containerstart, damit Immich, Analyse-, Backup- und andere Anwendungen nicht gleichzeitig erneut Verbindungen herstellen oder Migrationen ausführen. Verwenden Sie Gesundheits- und Bereitschaftsprüfungen, die warten, bis PostgreSQL nutzbar ist. Vermeiden Sie jedoch enge Wiederholungsschleifen, die eine Verbindungsflut erzeugen, während sich die Datenbank noch erholt.

Der ZimaSpace-Leitfaden zur Sicherheit einer externen Immich-Datenbank markiert eine wichtige Grenze: Sobald PostgreSQL vom Standard-Stack getrennt wird, werden Zuständigkeiten für Version, Erweiterungen, Berechtigungen, Backups und Rollbacks ausdrücklich festgelegt. Ein Verbindungsproxy oder ein zusätzlicher Datenbank-Host sollte nicht ausschließlich eingeführt werden, um langsame Abfragen oder überlasteten Speicher zu verbergen.

Wenn viele Sitzungen inaktiv sind und die hohe Anzahl an Anwendungen gerechtfertigt ist, kann ein Verbindungspooler in bestimmten PostgreSQL-Architekturen die Anzahl der Backend-Sitzungen verringern. Testen Sie zuvor jedoch genau die verwendete Immich-Version, Migrationen, Transaktionssemantik und das Verhalten vorbereiteter Anweisungen. Pooling ist kein Ersatz für die Behebung eines außer Kontrolle geratenen Clients oder einer überlasteten Datenbank.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Validieren Sie die Konfiguration mit gleichzeitigen Uploads, Suchvorgängen, Jobs und Neustarts

Erstellen Sie eine reproduzierbare Spitzenlast: Führen Sie repräsentative mobile Uploads, eine ältere Such- oder Browsing-Aktion und die übliche Mischung von Hintergrundaufgaben aus, während die anderen erwarteten Container aktiv sind. Erfassen Sie die Anzahl der Verbindungen nach Benutzer und Status, Fehler beim Abruf oder bei Anfragen, die Abfragelatenz, CPU- und Speicherauslastung der Datenbank sowie die Festplattenlatenz. Wiederholen Sie den Test nach jeweils einer Änderung.

Eine funktionierende Konfiguration hält die Sitzungen mit administrativer Reserve unterhalb der Fehlergrenze, vermeidet Fehler wie „zu viele Clients“, hält die Abfragelatenz innerhalb des für den Haushalt festgelegten Zielwerts und ermöglicht es den Warteschlangen, sich nach der Spitzenlast zu leeren. Weitere Verbindungen sind nur dann gerechtfertigt, wenn Anfragen tatsächlich auf eine Sitzung warten, während die Datenbank noch über CPU-, Speicher- und I/O-Kapazität verfügt.

Starten Sie den Anwendungs-Stack und anschließend den Host einmal neu, um den höchsten Verbindungsschub zu testen. Tritt der Fehler nur beim Start auf, beheben Sie die Reihenfolge oder das Wiederholungsverhalten, statt das dauerhafte Limit zu erhöhen. Wenn sich Sitzungen mit der Zeit ansammeln, erfassen Sie die zugehörigen Benutzer und Abfragen und untersuchen Sie dieses Leckmuster anhand von Versionen und Belegen zum Verbindungsstatus.