Jak skrócić czas uruchamiania Immich po ponownym uruchomieniu systemu

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 Reduce Immich Startup Time After Reboot - Zima Store Online

Jeśli Immich staje się użyteczny dopiero długo po ponownym uruchomieniu serwera domowego, zmierz, która zależność jest gotowa jako ostatnia, zanim spróbujesz „przyspieszyć” samą aplikację.

Ponowne uruchomienie może sprawić, że montowanie pamięci masowej, PostgreSQL, ścieżki sieciowe, DNS lub inne usługi będą dostępne w innej kolejności niż podczas zwykłego restartu Immich. Przydatną miarą nie jest moment, w którym Docker informuje o uruchomieniu kontenera, lecz czas od uruchomienia hosta do chwili, gdy baza danych przyjmuje rzeczywiste żądania, wymagane zasoby są zamontowane, Immich przestaje ponawiać próby połączenia z zależnościami, a klient może wczytać oś czasu. Zarejestruj tę sekwencję raz, a następnie usuń rzeczywiste opóźnienie lub pętlę ponawiania prób.

Zmierz oś czasu uruchamiania przed wprowadzeniem zmian

Uruchom ponownie serwer w oknie serwisowym i oznacz czas czterech zdarzeń: dostępności hosta, zamontowania pamięci masowej związanej z Immich, uzyskania przez bazę danych stanu gotowości oraz dostępności Immich z poziomu klienta. Zapisz także czasy uruchomienia kontenerów, ich stany zdrowia, liczbę restartów i pierwszy użyteczny wpis w dzienniku każdego serwisu. Dzięki temu „uruchamianie wydaje się powolne” zmieni się w konkretnie określone opóźnienie.

Porównaj wynik ze zwykłym restartem stosu wykonanym po pełnym uruchomieniu hosta. Jeśli Immich uruchamia się szybko później, ale wolno tylko podczas startu systemu, wąskim gardłem jest prawdopodobnie kolejność lub gotowość zależności poza aplikacją. Jeśli oba scenariusze są równie powolne, sprawdź operacje bazy danych, opóźnienia pamięci masowej, migracje lub obciążenie procesora.

Nie optymalizuj wszystkich warstw jednocześnie. Wynikiem tego etapu powinno być wskazanie pierwszego komponentu, którego gotowość jest opóźniona względem czasu uruchomienia kontenera lub który wielokrotnie zmusza Immich do ponawiania prób.

Sprawdź, czy pamięć masowa jest gotowa przed uruchomieniem Immich

Upewnij się, że każda ścieżka montowania i każda ścieżka oparta na zasobach sieciowych istnieje oraz zawiera oczekiwane dane, zanim uruchomią się usługi Immich. Punkt montowania może istnieć jako pusty katalog lokalny, podczas gdy rzeczywisty dysk lub udział NAS jest nadal niedostępny. W takiej sytuacji aplikacja może uruchomić się z niewłaściwym widokiem systemu plików.

Jeśli baza danych lub multimedia znajdują się na pamięci masowej, która pojawia się późno podczas uruchamiania systemu, ustaw zależność usługi od tego montowania na poziomie hosta albo opóźnij uruchomienie stosu do czasu zweryfikowania dostępności montowania. Test powinien sprawdzać rzeczywiście zamontowany system plików lub znacznik kontrolny, a nie tylko istnienie nazwy katalogu.

Po dostosowaniu gotowości pamięci masowej uruchom ponownie serwer i porównaj te same znaczniki czasu. Udana zmiana eliminuje ponawianie prób lub zachowanie związane z pustą ścieżką, nie zmieniając konfiguracji Immich w stanie ustalonym. Jeśli pamięć masowa była gotowa na długo przed bazą danych, przejdź do analizy sekwencji zależności zamiast dodawać arbitralne liczniki czasu uśpienia.

Poczekaj, aż baza danych będzie gotowa, a nie tylko uruchomiona

PostgreSQL może mieć uruchomiony kontener, zanim będzie gotowy do obsługi obciążenia aplikacji, zwłaszcza po nieprawidłowym zatrzymaniu, opóźnieniu pamięci masowej, inicjalizacji lub odzyskiwaniu danych. Porównaj przejście bazy danych do stanu zdrowego z pierwszymi błędami połączeń Immich w dziennikach uruchamiania.

Prosta kolejność uruchamiania może uruchomić zależny kontener, zanim usługa, której potrzebuje, faktycznie będzie gotowa. Jeśli używana wersja Compose i definicje usług to obsługują, sprawdzanie zależności na podstawie stanu zdrowia pozwala odróżnić „kontener uruchomiony” od „zależność gotowa”. Wykorzystaj je do usunięcia możliwych do uniknięcia cykli ponownego łączenia, a nie do ukrywania powolnej lub niesprawnej zależności.

Kontrola gotowości powinna być wąska i mieć praktyczne znaczenie. Sprawdzenie bazy danych powinno potwierdzać, że może przyjąć połączenie wymagane przez Immich; nie powinno wykonywać kosztownego zapytania, które samo wprowadza opóźnienie. Gdy gotowość bazy danych będzie stale poprzedzać uruchomienie Immich, ponownie wykonaj test po ponownym uruchomieniu hosta, zanim zmienisz cokolwiek innego.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Oddziel pętle ponawiania prób od uzasadnionych prac startowych

Jeśli pamięć masowa i PostgreSQL są gotowe, ale Immich nadal uruchamia się znacznie dłużej po ponownym uruchomieniu, sprawdź dzienniki aplikacji i procesów roboczych pod kątem powtarzających się błędów połączeń, nieudanych kontroli stanu zdrowia, migracji, inicjalizacji zadań lub presji na zasoby. Powtarzające się błędy w stałych odstępach często wskazują na oczekiwanie; ciągłe obciążenie procesora lub dysku przy widocznym postępie wskazuje na rzeczywiste prace startowe.

Kolejność zależności działa najlepiej w połączeniu z sensownymi kontrolami stanu zdrowia, a nie z krótkimi, stałymi opóźnieniami. Wzorzec kontroli stanu zdrowia w Compose może pomóc zapobiec sytuacji, w której aplikacja zaczyna działać równocześnie z bazą danych lub pamięcią podręczną, które nadal się inicjalizują. Kontrole powinny odzwierciedlać rzeczywistość; skracanie odstępów do czasu, aż niesprawna usługa zacznie wyglądać na zdrową, nie poprawia uruchamiania.

Jeśli podczas uruchamiania rośnie liczba restartów, zatrzymaj tę lawinę i ustal, która zależność jako pierwsza staje się niedostępna, zanim dostroisz parametry procesora, pamięci lub uruchamiania obrazu. Sprawdzenie zależności powodującej pętlę restartów kontenera pomaga odróżnić powolny warunek wstępny od problemu wewnątrz samego Immich.

Uruchom ponownie serwer i sprawdź rzeczywisty czas do gotowości

Po wprowadzeniu jednej ukierunkowanej zmiany wykonaj pełne ponowne uruchomienie hosta i zapisz te same znaczniki czasu. Rzeczywista poprawa powinna skrócić odstęp między gotowością zależności a użytecznością Immich po stronie klienta, nie powodując nowych pętli restartów, brakujących montowań ani błędów w tle.

Przetestuj więcej niż tylko stronę logowania w przeglądarce. Otwórz kilka starszych zdjęć, wykonaj wyszukiwanie, wczytaj reprezentatywne nagranie, potwierdź połączenie klienta mobilnego i prześlij jeden nieistotny plik, aby sprawdzić zarówno ścieżki odczytu, jak i zapisu. Z punktu widzenia gospodarstwa domowego serwer nie jest „uruchomiony”, dopóki te typowe operacje nie działają.

Wykonaj drugie ponowne uruchomienie po pierwszym udanym teście, aby upewnić się, że wynik nie był dziełem przypadku związanego z pamięcią podręczną ani jednorazowym zdarzeniem dotyczącym czasu odpowiedzi sieci. Jeśli uruchamianie nadal jest niestabilne, zachowaj ślady uruchamiania i skup się na komponencie, którego gotowość różni się między kolejnymi próbami. Nie ukrywaj zmienności za pomocą dłuższego stałego opóźnienia, chyba że nie masz lepszego sygnału gotowości.