Jak zoptymalizować połączenia z bazą danych Immich dla równoczesnych kontenerów

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

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

Zoptymalizuj połączenia z bazą danych Immich, mierząc łączne zapotrzebowanie na sesje ze strony wszystkich procesów Immich i innych klientów PostgreSQL, zamiast w pierwszej kolejności zwiększać max_connections. Baza danych musi mieć wystarczającą liczbę sesji na rzeczywiste obciążenie oraz rezerwę administracyjną, ale nadmierna współbieżność może zwiększyć zużycie pamięci i rywalizację o zasoby bez przyspieszania zapytań.

Na domowym serwerze z wieloma kontenerami rejestruj aktywne, bezczynne i oczekujące połączenia wraz z opóźnieniem zapytań, użyciem procesora, pamięci i opóźnieniem pamięci masowej podczas normalnego użytkowania oraz jednoczesnego uruchamiania usług. Błąd „zbyt wielu klientów” może wynikać ze zbiorczej konfiguracji, innej usługi lub lawiny restartów, nawet gdy pojedynczy kontener Immich wydaje się mieć niewielkie zapotrzebowanie.

Przed zmianą limitów zinwentaryzuj wszystkich klientów PostgreSQL

Wymień każdy proces serwera Immich lub replikę, zadanie migracji/konserwacji, zadanie tworzenia kopii zapasowej, narzędzie monitorujące oraz niezależną aplikację łączącą się z tą samą instancją PostgreSQL. Jeśli to możliwe, przydziel im osobnych użytkowników bazy danych, aby pg_stat_activity pokazywało, kto utrzymuje sesje. Zapisz bieżącą wartość max_connections i zachowaj jedną administracyjną ścieżkę dostępu na potrzeby reagowania na incydenty.

W dyskusji o błędzie „zbyt wielu klientów” w Immich znajduje się komentarz projektowy, zgodnie z którym Immich używał w tamtej wersji domyślnej puli składającej się z 10 połączeń. W osobnej dyskusji z 2026 roku zauważono, że wiele procesów roboczych Immich może utrzymywać własne pule. Traktuj te wartości jako kontekst implementacyjny zależny od wersji, a nie jako liczbę, którą można bezrefleksyjnie mnożyć w przyszłych wydaniach. Jeśli baza danych już zbliża się do limitu połączeń, gdy Immich jest bezczynny, przed dostrajaniem Immich ustal, kto jest właścicielem tych sesji. Jeśli aktywnych sesji jest niewiele, ale zapytania działają wolno, liczba połączeń może być objawem opóźnień pamięci masowej lub zapytań, a nie głównym wąskim gardłem.

Utwórz budżet połączeń na podstawie zmierzonej współbieżności

Zarezerwuj sesje na potrzeby administracji bazą danych, narzędzi tworzenia i odtwarzania kopii zapasowych, migracji oraz monitorowania.

Następnie rozdziel pozostałe połączenia aplikacyjne między jednocześnie działające procesy Immich i inne aplikacje. Celem jest pula wystarczająco duża, aby normalna praca nie musiała niepotrzebnie czekać, ale nie większa, niż baza danych może efektywnie obsłużyć.

Analiza doboru rozmiaru puli połączeń w PostgreSQL opisuje idealną pulę jako wystarczająco dużą na normalne zapotrzebowanie, ale możliwie małą, ponieważ mniejsza liczba sesji zaplecza ogranicza rywalizację o zasoby. Zastosuj tę zasadę do zmierzonego zapotrzebowania Immich, zamiast kopiować rozmiar puli serwera internetowego z innego obciążenia.

Jeśli wydanie Immich nie udostępnia obsługiwanej kontroli rozmiaru puli, nie modyfikuj wewnętrznych mechanizmów wyłącznie po to, aby osiągnąć określoną liczbę. Kontroluj to, na co masz wpływ: liczbę replik aplikacji, niezależnych klientów, harmonogram restartów, nakładanie się kopii zapasowych oraz pojemność bazy danych. Po zmianie wersji ponownie oceń obsługiwaną konfigurację.

Ogranicz częste tworzenie połączeń i oczekiwanie bazy danych przed dodaniem kolejnych sesji

Rozłóż w czasie uruchamianie kontenerów, aby Immich, analityka, zadania tworzenia kopii zapasowych i inne aplikacje nie łączyły się ponownie ani nie wykonywały migracji jednocześnie. Używaj kontroli stanu i gotowości, które czekają, aż PostgreSQL będzie używalny, ale unikaj krótkich pętli ponawiania prób, powodujących lawinę połączeń, gdy baza danych wciąż odzyskuje sprawność.

Poradnik ZimaSpace dotyczący bezpiecznego korzystania przez Immich z zewnętrznej bazy danych wyznacza ważną granicę: gdy PostgreSQL zostanie oddzielony od domyślnego stosu, kwestie wersji, rozszerzeń, uprawnień, kopii zapasowych i wycofywania zmian stają się jawne. Nie należy wprowadzać proxy połączeń ani dodatkowego hosta bazy danych wyłącznie po to, aby ukryć wolne zapytania lub przeciążoną pamięć masową.

Jeśli wiele sesji jest bezczynnych, a duża liczba aplikacji jest uzasadniona, menedżer puli połączeń może w niektórych architekturach PostgreSQL ograniczyć liczbę sesji zaplecza, ale dopiero po przetestowaniu konkretnej wersji Immich, migracji, semantyki transakcji i obsługi przygotowanych instrukcji. Pooling nie zastępuje naprawy wadliwego klienta ani przeciążonej bazy danych.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zweryfikuj konfigurację podczas równoczesnego przesyłania, wyszukiwania, zadań i restartu

Przygotuj powtarzalny test szczytowego obciążenia: wykonuj reprezentatywne przesyłanie z urządzeń mobilnych, starsze wyszukiwanie lub przeglądanie oraz zwykły zestaw zadań w tle, gdy działają także inne oczekiwane kontenery. Rejestruj liczbę połączeń według użytkownika i stanu, błędy uzyskiwania połączenia lub żądania, opóźnienie zapytań, użycie procesora i pamięci przez bazę danych oraz opóźnienie dysku. Następnie powtórz test po wprowadzeniu jednej zmiany.

Poprawna konfiguracja utrzymuje liczbę sesji poniżej poziomu powodującego awarie, pozostawia rezerwę administracyjną, eliminuje błędy „zbyt wielu klientów”, utrzymuje opóźnienie zapytań w docelowym zakresie dla gospodarstwa domowego i pozwala opróżnić kolejki po szczycie. Większa liczba połączeń jest uzasadniona tylko wtedy, gdy żądania rzeczywiście czekają na sesję, a baza danych nadal ma dostępną moc obliczeniową, pamięć i przepustowość operacji wejścia-wyjścia.

Uruchom ponownie stos aplikacji, a następnie raz hosta, aby przetestować największy skok liczby połączeń. Jeśli awaria występuje tylko podczas uruchamiania, napraw kolejność uruchamiania lub zachowanie mechanizmu ponawiania prób zamiast zwiększać stały limit. Jeśli liczba sesji rośnie z czasem, zapisz właścicieli i zapytania tych sesji, a następnie zgłoś wzorzec wycieku wraz z wersjami i dowodami dotyczącymi stanów połączeń.