Dlaczego uruchamianie Jellyfin spowalnia wraz ze wzrostem biblioteki

Uruchamianie Jellyfin może się wydłużać wraz ze wzrostem biblioteki, ponieważ trzeba ponownie otworzyć lub przetworzyć więcej trwałych rekordów, stron bazy danych, metadanych i stanu pamięci podręcznej.

Większa kolekcja multimediów nie sprawia, że każdy etap uruchamiania skaluje się liniowo, a liczba terabajtów jest często mniej istotna niż liczba elementów, relacje metadanych, rozmiar bazy danych i oczekujące zadania konserwacyjne. Warto ustalić, który etap uruchamiania się wydłuża: otwieranie trwałego stanu, wykonywanie migracji, sprawdzanie bibliotek, rozgrzewanie pamięci podręcznych czy oczekiwanie na gotowość pamięci masowej i zależności.

Rozrost biblioteki zwiększa trwały stan, a nie tylko ilość danych multimedialnych

Jellyfin nie odbudowuje całej biblioteki multimediów z bajtów plików wideo przy każdym zwykłym uruchomieniu, ale większy katalog zwykle oznacza więcej wierszy bazy danych, identyfikatorów dostawców, osób, odwołań do grafik, relacji dotyczących stanu użytkowników i ścieżek systemu plików. Struktury te powiększają trwały stan, który trzeba otworzyć i odpytywać, dlatego zachowanie podczas uruchamiania może się zmienić nawet wtedy, gdy dyski z multimediami zapewniają wysoką przepustowość sekwencyjną.

Różnicę między rozmiarem katalogu a pojemnością na multimedia widać w projekcie migracji Jellyfin 10.11, w którym dane biblioteki były przenoszone i deduplikowane wewnątrz struktur bazy danych, a nie kopiowane z plików multimedialnych. Konwersja bazy danych biblioteki pokazuje, dlaczego liczba rekordów i prace związane ze schematem mogą mieć większe znaczenie dla uruchamiania niż łączna liczba terabajtów przechowywanych na serwerze NAS.

Granica jest taka, że sam rozrost biblioteki nie stanowi diagnozy. Jeśli mała baza danych czeka na brakujący montowany zasób sieciowy lub uszkodzoną wtyczkę, uruchamianie nadal może być powolne; jeśli bardzo duża baza danych jest otwierana z szybkiej pamięci lokalnej i nie ma zaległych zadań konserwacyjnych, uruchamianie może pozostać przewidywalne. Mierz rozmiar bazy danych i stan metadanych oddzielnie od surowej pojemności multimediów.

Strony bazy danych i indeksy zwiększają roboczy zestaw danych przy zimnym starcie

Wraz ze wzrostem bazy danych do obsługi zapytań wykonywanych podczas uruchamiania i pierwszych żądań biblioteki może być potrzebnych więcej stron. Zimny proces nie ma żadnych z tych stron we własnej pamięci, a na zimnym hoście może ich również brakować w pamięci podręcznej systemu plików. Serwer wykonuje więc więcej odczytów fizycznych, dopóki często używana część katalogu nie znajdzie się w pamięci i kolejne operacje wyszukiwania nie będą mogły jej ponownie wykorzystać.

Zachowanie rozgrzanej pamięci podręcznej pozwala kontrolować ten efekt: pierwszy dostęp może być wolniejszy, ponieważ trzeba pobrać metadane i strony, natomiast ponowny dostęp jest szybszy bez żadnych zmian w sprzęcie procesora, dysku czy sieci. Dlatego czas zimnego uruchomienia i czas działania w stanie ustalonym po rozgrzaniu należy mierzyć osobno, zamiast traktować je jako dwie próbki jednej rzekomo stabilnej wartości.

Problem pojawia się, gdy aktywny roboczy zestaw danych nie może pozostać w pamięci. Presja na pamięć, ścisłe limity kontenera lub konkurujące usługi mogą wielokrotnie usuwać przydatne strony z pamięci, sprawiając, że każda nawigacja wygląda jak zimny start. W takim przypadku rozmiar biblioteki ma znaczenie z powodu presji na pamięć, a nie dlatego, że Jellyfin celowo ponownie skanuje każdy element podczas uruchamiania.

Duże aktualizacje mogą zamienić rozmiar biblioteki w czas migracji

Większość zwykłych restartów nie wymaga przepisywania schematu, ale duże wydania mogą wprowadzać jednorazowe transformacje, których koszt zależy od ilości istniejącego stanu. Duży katalog może więc sprawić, że jedno uruchomienie po aktualizacji będzie znacznie wolniejsze niż kolejnych dziesięć uruchomień. Traktowanie tego pojedynczego zdarzenia migracji jako stałej wartości bazowej zawyża długoterminowy wpływ rozrostu biblioteki.

Jellyfin wyraźnie ostrzegał, że początkowa aktualizacja do wersji 10.11 może obejmować migracje trwające kilka godzin, zależnie od rozmiaru i stanu biblioteki. To zależne od rozmiaru okno migracji jest mocnym argumentem za rozdzieleniem uruchamiania po aktualizacji od zwykłego uruchamiania, ponieważ ten sam serwer nie powinien ponownie wykonywać pełnej konwersji po pomyślnym zapisaniu nowego trwałego stanu.

Granica jest powtarzalność. Jeśli przy każdym restarcie wygląda na to, że rozpoczyna się ta sama długa migracja, zachowaj logi i sprawdź, czy usługa ponownie otwiera właściwy trwały katalog, zamiast uznawać opóźnienie za normalny efekt skalowania. Skończone prace jednorazowe są oczekiwane; powtarzające się identyczne migracje wskazują na problemy z trwałością danych, wycofywaniem zmian lub stanem błędu.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Opóźnienia pamięci masowej mają większe znaczenie, gdy mnożą się małe operacje

Rozrastające się biblioteki zwykle zwiększają liczbę operacji na bazie danych i metadanych, przez co opóźnienia dostępu stają się bardziej widoczne. Dyski HDD nadal nadają się do dużych sekwencyjnych odczytów multimediów, ale stan aplikacji obejmuje mniejsze i mniej sekwencyjne operacje. Nawet niewielki wzrost liczby stron lub plików używanych podczas uruchamiania może więc uwydatnić różnicę między lokalną pamięcią masową o niskich opóźnieniach a wolniejszą ścieżką mechaniczną lub zdalną.

Własny model pamięci masowej Jellyfin zaleca dyski SSD dla plików Jellyfin, ponieważ są one intensywnie wykorzystywane w losowych operacjach dostępu, podczas gdy pamięć na multimedia jest ograniczana przede wszystkim przez szybkość sekwencyjną. Wskazówki dotyczące pamięci masowej stanu aplikacji wyjaśniają, dlaczego przeniesienie samej bazy danych i metadanych do warstwy o niższych opóźnieniach może zmienić czas uruchamiania i przeglądania bez przenoszenia całej biblioteki multimediów.

Granica dotyczy mierzonego kolejkowania, a nie rodzaju dysku. Dysk SSD współdzielony z innym procesem wykonującym ciągły zapis również może powodować opóźnienia, a dysk HDD może wystarczyć dla niewielkiego, rozgrzanego stanu aplikacji. Porównaj opóźnienia operacji wejścia-wyjścia i długość kolejki podczas uruchamiania przy tej samej bibliotece, zanim uznasz, że wzrost pojemności automatycznie wymaga innej technologii pamięci masowej.

Mierz uruchamianie etapami, zanim uznasz serwer za zbyt słaby

Zapisz pięć znaczników czasu: uruchomienie procesu, otwarcie trwałej bazy danych, zakończenie migracji lub konserwacji, dostępność użytecznego interfejsu WWW oraz pierwsze reprezentatywne żądanie biblioteki. Powtórz test raz na zimno i raz po czystym restarcie, gdy nie ma oczekującej aktualizacji. Dodaj rozmiar bazy danych, ilość wolnej pamięci i opóźnienia pamięci masowej, aby powiązać wydłużający się etap z zasobem, zamiast traktować rozmiar biblioteki jako abstrakcyjną etykietę.

Struktura analizy nasycenia zasobów pomaga interpretować wyniki: kolejki procesora, presja na pamięć, opóźnienia pamięci masowej lub oczekiwanie na sieć powinny rosnąć wraz z etapem, który ograniczają. Jeśli czas uruchamiania rośnie, a wszystkie lokalne zasoby pozostają w dobrym stanie, sprawdź gotowość zależności i logi aplikacji, zanim kupisz sprzęt lub przeniesiesz bibliotekę.

Pozostań przy obecnym hoście, jeśli zwykłe uruchamianie jest stabilne, migracje kończą się jednokrotnie, a pierwsze rozgrzane żądanie wraca do oczekiwanego poziomu bazowego. Rozważ zmianę lokalizacji danych lub zwiększenie zasobów, gdy ten sam etap wydłuża się w kolejnych pomiarach, a odpowiadający mu zasób pozostaje trwale przeciążony. Wstrzymaj się ze zmianami danych, jeśli uruchamianie zgłasza błędy integralności, brakujące montowania lub stan świeżo skonfigurowanego serwera.