Jaki limit pamięci należy ustawić dla Immich?

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.

Nie ustawiaj jednego limitu pamięci dla Immich na podstawie uniwersalnej wartości w GB. Docelowa ilość pamięci RAM dla hosta i limit dla pojedynczego kontenera rozwiązują różne problemy: host musi obsłużyć cały stos, a limit kontenera powinien chronić hosta, nie przerywając prawidłowego działania Immich.

Przeglądanie przetworzonej biblioteki może wydawać się mało wymagające, podczas gdy zimny start uczenia maszynowego, duży import, generowanie miniatur, analiza twarzy lub przetwarzanie wideo zużywa znacznie więcej pamięci. Zmierz najbardziej wymagające obciążenie, którego rzeczywiście potrzebujesz, pozostaw zapas dla PostgreSQL i systemu operacyjnego, a powtarzające się zabicia przez OOM traktuj jako oznakę nieudanego limitu, a nie normalnego ograniczania zasobów.

Zmierz presję na pamięć przed wyborem limitu

Rejestruj zużycie pamięci w trzech stanach: podczas spokojnego przeglądania, reprezentatywnego codziennego przesyłania oraz najcięższego planowanego zadania działającego w tle. Zapisuj zużycie kontenera, dostępną pamięć hosta, aktywność pamięci wymiany, zdarzenia OOM oraz to, czy zadania nadal postępują. Pojedynczy szczyt z docker stats nie wystarczy, ponieważ księgowanie pamięci w systemie Linux obejmuje kilka rodzajów pamięci o różnej podatności na odzyskanie.

Przydatny podział pamięci cgroup Dockera rozróżnia pamięć anonimową, pamięć podręczną opartą na plikach oraz pamięć slab, zamiast traktować całą wartość surową jako równie niebezpieczną. Stabilna pamięć podręczna plików przy zdrowym zapasie pamięci hosta to co innego niż stale rosnąca pamięć anonimowa, presja na pamięć wymiany lub rosnący licznik OOM cgroup podczas tego samego zadania Immich.

Zakończ ten etap, gdy potrafisz wskazać powtarzalny punkt maksymalnego zużycia i wyjaśnić, czy składa się on głównie z pamięci możliwej do odzyskania, czy z aktywnej pamięci roboczej. Jeśli zużycie nadal rośnie przy niezmienionym obciążeniu, kontener jest wielokrotnie zabijany przez OOM lub host zaczyna intensywnie korzystać z pamięci wymiany, przerwij dobieranie limitu na podstawie tego przebiegu i najpierw zdiagnozuj nietypowy wzrost.

Dobierz limit do najcięższego prawidłowego obciążenia Immich

Wybierz obciążenie, które musi pozostać obsługiwane po zastosowaniu limitu. W jednym gospodarstwie domowym może to być przesyłanie zdjęć z czterech telefonów przy jednoczesnym nadrabianiu zaległości przez Smart Search i zadania analizy twarzy; w innym — duży początkowy import, po którym następuje zwykłe przeglądanie. Podczas pomiarów nie zmieniaj zbioru danych, modeli, ustawień współbieżności ani innych kontenerów, aby limit odzwierciedlał jasno określony poziom usług.

Ustaw twardy limit powyżej zaobserwowanego szczytowego zużycia pamięci niepodlegającej odzyskaniu, zapewniając mierzalny zapas na krótkie skoki, a jednocześnie pozostawiając pamięć hosta dla PostgreSQL, pamięci podręcznej systemu plików, środowiska uruchomieniowego kontenerów i niezwiązanych z tym usług. Powiązana lista kontrolna ZimaSpace dotycząca oznak problemów z zasobami przy lokalnej sztucznej inteligencji jest przydatna, ponieważ przegrzewanie, korzystanie z pamięci wymiany i nagłe restarty ujawniają przeciążenie hosta, którego może nie pokazać wykres dotyczący wyłącznie Immich. Nie interpretuj jednorazowego dojścia kontenera do limitu jako dowodu, że potrzebujesz więcej pamięci RAM. Kluczowa jest granica awarii: czy to samo prawidłowe obciążenie wyraźnie zwalnia, traci zadania, stale korzysta z pamięci wymiany lub zostaje zabite przez OOM. Z drugiej strony limit jest zbyt luźny, jeśli Immich może wyczerpać zasoby bazy danych lub hosta, zanim jego własna grupa cgroup stanie się ograniczeniem.

Ogranicz obciążenie, zanim podniesiesz limit z powodu nietypowego wzrostu

Jeśli proponowany limit nie wystarcza tylko podczas jednej kategorii zadań działających w tle, przed podniesieniem wartości granicznej zmniejsz współbieżność tego zadania lub odizoluj dany etap. Uczenie maszynowe, generowanie miniatur, przetwarzanie wideo i praca bazy danych mogą mieć różne profile zużycia pamięci. Mniejsza aktywna partia może przetwarzać się wolniej, ale utrzyma responsywność interfejsu domowego i umożliwi hostowi odzyskanie sprawności.

Znaczenie mają również problemy zależne od wersji. W raporcie dotyczącym pamięci w Immich v3.0.3 opisano wzrost zużycia pamięci przez proces roboczy uczenia maszynowego aż do wywołania OOM przez limit cgroup w wyniku nieprawidłowego warunku związanego z lokalizacją. Ten przypadek nie określa typowego zużycia pamięci RAM przez Immich; pokazuje, dlaczego niewyjaśniony wzrost należy najpierw potraktować jako problem programowy lub konfiguracyjny, zanim trwale zwiększysz budżet hosta.

Po zmianie jednej zmiennej — współbieżności, modelu lub wersji — uruchom ponownie to samo obciążenie. Zachowaj zmianę tylko wtedy, gdy zarówno profil zużycia pamięci, jak i pierwotne zadanie poprawią się zgodnie z oczekiwaniami. Jeśli pamięć nadal rośnie bez osiągnięcia stabilnego poziomu, zachowaj logi i informacje o wersji oraz zgłoś problem, zamiast zamieniać twardy limit w coraz większą wartość.

Zweryfikuj limit po zimnym restarcie i cyklu dużego obciążenia

Uruchom hosta ponownie, aby pamięci podręczne i obecność modeli w pamięci zaczęły działanie ze znanego, zimnego stanu. Wykonaj zwykłe czynności logowania i przeglądania, a następnie reprezentatywne przesyłanie oraz zadanie działające w tle. Zapisz szczytowe zużycie pamięci anonimowej, pamięć podręczną, użycie pamięci wymiany, liczniki OOM, czas odpowiedzi bazy danych, czas opróżniania kolejki oraz to, czy inny ważny kontener pozostaje responsywny.

Poprawnie dobrany limit działa zarówno podczas zimnego startu, jak i najbardziej obciążającego normalnego cyklu, bez zabijania przez OOM, długotrwałego przeciążenia pamięci wymiany, powtarzających się restartów kontenera ani zatrzymywania opróżniania kolejki. Powinien również pozostawić hostowi wystarczający zapas na zadania naprawcze, takie jak zrzut bazy danych lub logowanie administracyjne, gdy Immich jest zajęty.

Jeśli nie powiedzie się wyłącznie sztuczny test obciążeniowy, a wszystkie zdefiniowane scenariusze domowe przejdą pomyślnie, udokumentuj zaakceptowaną granicę zamiast kupować pamięć RAM na potrzeby scenariusza, którego nie potrzebujesz.

Jeśli rzeczywiste obciążenie nie może przejść bez wyczerpania zasobów hosta, zmniejsz współbieżność, odizoluj uczenie maszynowe, dodaj pamięć lub przenieś konkurujące usługi, a następnie powtórz tę samą weryfikację przed uznaniem nowego limitu za bezpieczny.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.