Jak duża może być biblioteka Jellyfin na jednym hoście?

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 Large Can a Jellyfin Library Grow on a Single Host? - Zima Store Online

Nie istnieje uniwersalny, użyteczny limit liczby elementów w Jellyfin, który wskazywałby, kiedy jeden host jest „pełny”. Praktyczny limit pojawia się w momencie, gdy baza danych, pamięć, pamięć masowa, zaplanowane zadania lub jednoczesne odtwarzanie nie są już w stanie spełnić zakładanego czasu odpowiedzi.

Dwie biblioteki zawierające taką samą liczbę filmów mogą w zupełnie różnym stopniu obciążać serwer, ponieważ różnią się ilością metadanych, obrazów rozdziałów, danych trickplay, wykorzystaniem pamięci sieciowej, zestawem klientów i zapotrzebowaniem na transkodowanie. Zmierz działanie hosta przy rzeczywistym obciążeniu i określ granicę, którą można ponownie sprawdzić po każdym większym powiększeniu biblioteki.

Zacznij od rozmiaru bazy danych, a nie liczby plików multimedialnych

Jellyfin przechowuje stan biblioteki w bazie danych, podczas gdy pliki multimedialne pozostają w systemie plików. W miarę rozrastania się katalogu pierwszym przydatnym wskaźnikiem jest rozmiar i działanie zbioru danych Jellyfin, a nie łączna liczba terabajtów plików filmowych.

Dokumentacja pamięci masowej Jellyfin wskazuje, że baza danych średniej wielkości biblioteki może osiągnąć około 10–100 GB, i zaleca przechowywanie bazy danych na lokalnym nośniku zamiast w udziale sieciowym. wskazówki dotyczące przechowywania bazy danych

Rejestruj rozmiar bazy danych, wolne miejsce na woluminie danych oraz czas potrzebny na otwarcie dużych widoków biblioteki lub wyszukanie elementu po rozgrzaniu pamięci podręcznej. Jeśli wartości te pozostają stabilne, gdy rośnie pojemność multimediów, sam rozmiar plików multimedialnych nie przekroczył jeszcze limitu pojedynczego hosta.

Sprawdź zapas pamięci po rozgrzaniu bazy danych

Zużycie pamięci ma większe znaczenie w nowszych wydaniach Jellyfin, ponieważ serwer może przechowywać w pamięci dużą ilość danych bazy, aby ograniczyć odczyty z dysku. Host, który przy mniejszym katalogu wydawał się mieć duży zapas, może więc wykazywać większe ustabilizowane zużycie pamięci RAM po rozrośnięciu się biblioteki.

Informacje o wydaniu Jellyfin 10.11 wyjaśniają, że silnik bazy danych intensywnie buforuje metadane w pamięci i może wykorzystywać pamięć do rozmiaru bazy danych biblioteki, zwalniając ją, gdy inne procesy jej potrzebują. buforowanie bazy danych w pamięci

Obserwuj dostępną pamięć i aktywność wymiany po rozgrzaniu pamięci podręcznej podczas normalnego przeglądania. Sygnałem ostrzegawczym nie jest samo wysokie zużycie pamięci podręcznej, lecz utrzymująca się presja na pamięć, użycie pliku wymiany lub opóźnienia pojawiające się, gdy Jellyfin konkuruje z innymi kontenerami i znikające po usunięciu tego obciążenia.

Zmierz czas zadań działających w tle, które rosną wraz z biblioteką

Skanowanie biblioteki, odświeżanie metadanych, wyodrębnianie obrazów, obsługa napisów i inne zaplanowane zadania mogą stać się pierwszym ograniczeniem skalowania, nawet gdy odtwarzanie nadal działa płynnie. Zmierz czas trwania tych zadań i sprawdź, czy nakładają się na godziny, w których użytkownicy faktycznie korzystają z serwera.

Wyodrębnianie obrazów rozdziałów to przykład funkcji, w przypadku której Jellyfin dokumentuje bezpośredni koszt skalowania: włączenie wyodrębniania podczas skanowania biblioteki może znacznie spowolnić skanowanie, szczególnie w przypadku dużych bibliotek. koszt skanowania obrazów rozdziałów

Jeśli pełne skanowanie zajmuje teraz większość okna konserwacji, najpierw ogranicz zbędne operacje lub przenieś kosztowne zadania poza godziny szczytu. Dłuższe skanowanie nie oznacza automatycznie, że host ma zbyt małą wydajność; staje się problemem pojemności dopiero wtedy, gdy konserwacja regularnie koliduje z interaktywnym użytkowaniem lub nigdy nie kończy się niezawodnie.

-15% OFF

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

Single board computer zimaboard2

Oddziel skalę biblioteki od skali transkodowania

Ogromny katalog nie musi sprawiać, że strumień odtwarzany bezpośrednio będzie kosztowny, podczas gdy mały katalog może przeciążyć procesor, gdy kilku niekompatybilnych klientów zażąda transkodowania wideo. Traktuj skalę katalogu i konwersję podczas odtwarzania jako dwa oddzielne testy wydajności.

Przeprowadź powtarzalny test odtwarzania z używanym przez Ciebie zestawem klientów: jeden strumień odtwarzany bezpośrednio, jedno typowe transkodowanie, a następnie oczekiwany szczyt jednoczesnych odtworzeń. Jeśli katalog rośnie, ale wyniki tych testów odtwarzania pozostają bez zmian, nie osiągnięto limitu transkodowania z powodu rozmiaru biblioteki.

Gdy nasycenie procesora pojawia się wyłącznie podczas transkodowania, dostosuj kodeki, akcelerację sprzętową lub zgodność klientów, zanim obwinisz bazę danych. przewodnik po akceleracji sprzętowej jest właściwszym kolejnym krokiem niż przenoszenie sprawnej bazy metadanych na drugi serwer.

Sprawdź opóźnienia pamięci masowej i dostępność multimediów podczas skanowania

Duże biblioteki często obejmują kilka dysków lub serwer NAS, więc ścieżka dostępu do multimediów może stać się warstwą ograniczającą wydajność. Porównaj interaktywne przeglądanie i odtwarzanie przy uruchomionym skanowaniu biblioteki oraz bez niego, a także obserwuj kolejki dyskowe lub opóźnienia udziału sieciowego na ścieżce multimediów.

Jellyfin zaleca montowanie pamięci Samba lub NFS bezpośrednio w systemie operacyjnym i ostrzega, że zaplanowana konserwacja może usunąć elementy biblioteki, jeśli pamięć masowa będzie niedostępna w momencie uruchomienia zadania. pamięć sieciowa i ostrzeżenie dotyczące konserwacji

Jeśli baza danych działa szybko, ale katalogi multimediów okresowo znikają lub skanowanie metadanych blokuje się na powolnym udziale, dodanie procesora nie rozwiąże rzeczywistego wąskiego gardła. Najpierw napraw niezawodność montowania, opóźnienia pamięci masowej lub harmonogram zadań, a następnie powtórz ten sam test.

Określ własny limit pojedynczego hosta za pomocą powtarzalnego testu

Przed kolejnym powiększeniem biblioteki przygotuj niewielką kartę wyników: opóźnienie wyszukiwania po rozgrzaniu pamięci podręcznej, czas otwierania dużej kolekcji, czas pełnego skanowania, rozmiar bazy danych, dostępną pamięć RAM, szczytowe opóźnienie pamięci masowej oraz jeden reprezentatywny test jednoczesnego odtwarzania. Za każdym razem korzystaj z tych samych pomiarów.

Typowy schemat działania domowego centrum multimedialnego już oddziela pamięć masową multimediów od warstwy aplikacji Jellyfin; zachowaj ten podział w testach, aby wiedzieć, czy spowolnienie wynika z hosta, ścieżki pamięci masowej czy klientów.

Uznaj, że pojedynczy host przestał wystarczać, dopiero gdy mierzony cel wielokrotnie nie jest osiągany po zastosowaniu niskiego ryzyka optymalizacji: żądania interaktywne pozostają powolne, skanowanie nie mieści się w oknie konserwacji, presja na pamięć powoduje użycie pliku wymiany, nie można wyeliminować opóźnień pamięci masowej lub wymagane transkodowania przekraczają dostępną moc obliczeniową. Wtedy dane wskażą, który zasób należy rozbudować, zamiast wymuszać arbitralny próg liczby elementów.