Dlaczego Immich zwraca sporadyczne błędy podczas importowania dużych bibliotek mobilnych?

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.

Why Does Immich Return Intermittent Errors During Large Mobile-Library Imports? - Zima Store Online

Okresowe błędy Immich podczas dużego importu z telefonu zwykle oznaczają, że jedna warstwa zawodzi przy nakładaniu się obciążeń, a nie że cała biblioteka lub każdy przesłany plik jest uszkodzony.

Duże importy łączą działanie aplikacji mobilnej w tle, długotrwałe żądania, limity odwrotnego proxy lub tunelu, zapisy do bazy danych, operacje wejścia-wyjścia pamięci masowej, generowanie miniatur i przetwarzanie wideo oraz kolejki uczenia maszynowego. Najpierw zapisz niewielką grupę nieudanych plików i odpowiadające im znaczniki czasu. Następnie ustal, czy awaria zaczyna się na telefonie, w ścieżce sieciowej, na serwerze aplikacji czy w przeciążonej zależności.

Najpierw sklasyfikuj grupę błędów, zanim ponowisz próbę dla wszystkiego

Grupuj błędy według typu multimediów, rozmiaru pliku, urządzenia źródłowego, ścieżki sieciowej i czasu. Jeśli zawodzą tylko duże filmy, przed analizą procesora sprawdź czas trwania żądania i limity przesyłania. Jeśli losowe zdjęcia i filmy zawodzą w tych samych okresach dużego obciążenia, bardziej prawdopodobne stają się wspólne zasoby serwera lub niestabilność sieci.

Opublikowane w 2026 roku zgłoszenie użytkownika Immich opisujące liczne błędy przesyłania z urządzenia mobilnego jest przydatne, ponieważ pokazuje, jak duża zaległość na telefonie może ujawnić powtarzające się awarie wymagające diagnostyki poszczególnych elementów i ścieżek. Nie dowodzi jednak istnienia jednego uniwersalnego błędu klienta mobilnego.

Nie wybieraj opcji „ponów wszystko” jako pierwszego działania diagnostycznego. Zapisz nazwy lub identyfikatory dziesięciu nieudanych plików, jeden pomyślnie przesłany plik kontrolny oraz odpowiadające im okno logów klienta i serwera. Niewielka, znana grupa pozwala testować zmiany bez wywoływania kolejnej fali błędów, która ukryłaby pierwotne dowody.

Porównaj przesyłanie lokalne ze standardową ścieżką zdalną

Prześlij te same małe i duże pliki testowe przez stabilną lokalną sieć Wi-Fi bezpośrednio do zaufanego lokalnego punktu końcowego, a następnie powtórz próbę przez zwykle używaną zdalną nazwę hosta, VPN, tunel lub odwrotne proxy. Nie zmieniaj konta ani plików, aby główną zmienną była trasa.

Zgłoszenie dotyczące błędów kopii zapasowej dużych plików pokazuje, dlaczego limity żądań proxy lub tunelu należy sprawdzać w tej gałęzi diagnostycznej. Zgłoszone usługi i wartości progowe zależą od konkretnego wdrożenia; ogólny test polega na sprawdzeniu, czy bezpośredni transfer lokalny działa, a ścieżka zdalna konsekwentnie zawodzi.

Jeśli obie ścieżki zawodzą dla tych samych plików, kieruj się dowodami z serwera i pamięci masowej. Jeśli zawodzi tylko ścieżka zdalna, sprawdź maksymalny rozmiar treści, buforowanie żądań, limity bezczynności i odczytu, terminowanie TLS, zmiany sieci mobilnej oraz retransmisje. Zmiana współbieżności generowania miniatur nie naprawi żądania, które nigdy nie dociera w całości do Immich.

Powiąż błędy z rozrostem kolejki i presją na zasoby

Duże importy mogą nadal przyjmować przesyłane pliki, podczas gdy zadania w tle gromadzą się w kolejce. W okresie występowania błędów obserwuj procesor, presję na pamięć, opóźnienia wejścia-wyjścia bloków, responsywność bazy danych, ponowne uruchomienia kontenerów oraz ukończone zadania. Samo wysokie wykorzystanie zasobów nie jest dowodem; metryka musi zmieniać się w tym samym czasie co błędy.

Artykuł Dockera dotyczący monitorowania zasobów w kontenerach pokazuje wartość porównywania kontenerów zamiast odczytywania jednej średniej dla całego hosta. W systemie Linux połącz metryki kontenerów z danymi o pamięci masowej hosta i presji na pamięć dla tych samych znaczników czasu.

Jeśli presja na pamięć powoduje zamykanie kontenerów, opóźnienia pamięci masowej rosną wraz z błędami przesyłania lub czas odpowiedzi bazy danych gwałtownie wzrasta, gdy kolejka przestaje się posuwać, zmniejsz tylko obciążenie lub współbieżność odpowiedzialną za problem i powtórz test na tej samej grupie. Jeśli wykresy zasobów pozostają stabilne, przejdź do logów aplikacji i diagnostyki ścieżki sieciowej.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Traktuj współczynnik błędów i opóźnienia skrajne jako sygnały obciążenia

System może wyglądać na sprawny według średniego czasu odpowiedzi, podczas gdy niewielki odsetek żądań przekracza limit czasu w szczycie obciążenia. W kontrolowanym przedziale zapisuj liczbę prób przesłania, liczbę błędów, medianę czasu odpowiedzi oraz wolniejsze żądania skrajne. Dzięki temu „okresowe” staje się mierzalne, a nie anegdotyczne.

Struktura testów obciążeniowych stosowana w analizie błędów i opóźnień zaleca analizowanie klas statusów, problemów z połączeniem, rozkładów oraz korelacji szeregów czasowych. Nie musisz agresywnie obciążać rodzinnej biblioteki; zastosuj tę samą strukturę analizy do rzeczywistego tempa importu.

Jeśli znaczne zmniejszenie tempa napływu wyraźnie ogranicza liczbę błędów, a każdy pojedynczy plik przechodzi pomyślnie, obecny stos nie ma wystarczającego zapasu wydajności dla takiej intensywności importu. Jeśli te same pliki zawodzą nawet pojedynczo, problem dotyczy plików, ścieżki lub deterministycznego błędu oprogramowania, a nie ogólnego przeciążenia.

Zmniejsz jedno źródło presji i ponownie przetestuj ten sam schemat importu

Wybierz najbezpieczniejszą zmianę przewidywaną na podstawie dowodów: zmniejsz jedną współbieżność zadań w tle, wstrzymaj inny obciążający kontener, użyj trasy lokalnej, przenieś import poza okno tworzenia kopii zapasowej albo skoryguj limit czasu proxy. Nie zmieniaj jednocześnie limitów procesora, ustawień pamięci masowej, reguł proxy i wersji aplikacji.

Instrukcja ZimaSpace dotycząca przerywania kopii zapasowej zdjęć z telefonu przedstawia gałąź diagnostyki po stronie urządzenia mobilnego: planowanie zadań w tle, oryginały dostępne tylko w chmurze oraz zmieniające się warunki sieciowe mogą przerywać przesyłanie, nawet gdy serwer działa prawidłowo.

Test uznaj za pomyślny, gdy ustalona grupa przechodzi poprawnie, a ten sam większy import działa ze stabilnym współczynnikiem błędów, postępem kolejek i akceptowalną wydajnością interaktywną. Eskaluj problem, gdy błędy utrzymują się przy małym obciążeniu lub powtarzają dla identycznych plików; dołącz logi klienta, logi serwera, status proxy, wykresy zasobów, typ i rozmiar pliku oraz pierwsze żądanie, które zakończyło się błędem.