Oznaki, że Jellyfin przerósł obecny serwer domowy

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.

Signs That Jellyfin Has Outgrown Its Current Home Server - Zima Store Online

Jellyfin przerósł możliwości domowego serwera, gdy typowe obciążenia wielokrotnie nie osiągają założonej wydajności, a wąskie gardło nadal znajduje się po stronie serwera po wyeliminowaniu problemów z klientami, ścieżkami pamięci masowej i konfiguracją.

Nie traktuj pojedynczego skoku użycia procesora, powolnego skanowania ani jednej sesji z buforowaniem jako dowodu, że potrzebujesz nowego sprzętu. Za każdym razem używaj tego samego obciążenia testowego — przeglądania biblioteki, zaplanowanej konserwacji, bezpośredniego odtwarzania i reprezentatywnego transkodowania — a następnie obserwuj, który zasób osiąga nasycenie i czy zmiana konfiguracji o niskim ryzyku usuwa objaw.

Szukaj powtarzalnych problemów przy normalnym obciążeniu

Najsilniejszym sygnałem jest powtarzalność. Jeśli Jellyfin działa wolno tylko podczas nietypowego pełnego skanowania lub bezpośrednio po ponownym uruchomieniu, host może nadal być wystarczający. Jeśli to samo opóźnienie pojawia się każdego wieczoru przy tej samej liczbie strumieni albo każde zaplanowane zadanie powoduje zawieszenie interfejsu, granica wydajności staje się istotna w codziennej eksploatacji.

Wskazówki dotyczące rozwiązywania problemów z Jellyfin zalecają korzystanie z dzienników w celu odróżnienia awarii odtwarzania i transkodowania po stronie serwera od problemów, które nigdy do niego nie docierają. Dzięki temu dzienniki są przydatnym pierwszym kryterium oceny przed zakupem sprzętu. dzienniki rozwiązywania problemów z Jellyfin

Zapisuj przyczynę wyzwalającą test, czas trwania, użycie procesora, presję pamięci, opóźnienia dysku i tryb odtwarzania podczas dwóch lub trzech powtórzeń. Jeśli objaw zmienia się wraz ze zmianą obciążenia, masz ograniczenie charakterystyczne dla konkretnego zadania; jeśli występuje przy każdej operacji, najpierw sprawdź pamięć masową lub stan bazy danych.

Oddziel ograniczenie transkodowania od ogólnej powolności serwera

Otwórz panel Jellyfin podczas problematycznego odtwarzania i sprawdź, czy klient korzysta z bezpośredniego odtwarzania, bezpośredniego strumieniowania, remultipleksowania czy transkodowania. Bezpośrednie odtwarzanie powoduje bardzo małe obciążenie obliczeniowe w porównaniu z transkodowaniem wideo, dlatego tryb odtwarzania zmienia znaczenie tego, że serwer „nie wyrabia”.

Dokumentacja Jellyfin określa bezpośrednie odtwarzanie jako ścieżkę o najmniejszym obciążeniu, a transkodowanie wideo jako ścieżkę o największym obciążeniu. Zwraca również uwagę, że możliwości klienta decydują o tym, kiedy wymagane jest transkodowanie. tryb odtwarzania i działanie transkodowania

Jeśli host staje się bezużyteczny dopiero po rozpoczęciu co najmniej jednego transkodowania, przed wymianą serwera sprawdź akcelerację sprzętową i zgodność klienta. sprawdzenie transkodowania sprzętowego może ujawnić, że istniejący układ GPU lub iGPU ma niewykorzystaną wydajność.

Sprawdź, czy metadane i operacje na bazie danych nie zużywają zapasu wydajności

Serwer może płynnie odtwarzać multimedia, a mimo to działać coraz wolniej podczas wyszukiwania, otwierania dużych kolekcji lub odświeżania metadanych. Wskazuje to nie na czyste ograniczenie transkodowania, lecz na warstwę danych, opóźnienia pamięci masowej albo rywalizację o pamięć.

Nowsze wydania Jellyfin mogą buforować w pamięci dużą część bazy danych biblioteki. Informacje o wydaniu 10.11 wyjaśniają, że pamięć podręczna może urosnąć do rozmiaru bazy danych, przez co użycie RAM-u może wyglądać na wyższe w przypadku dużych bibliotek. buforowanie bazy danych w pamięci

Charakterystycznym objawem problemu jest utrzymująca się presja na zasoby: użycie pliku wymiany, powolne wyszukiwanie mimo rozgrzanej pamięci podręcznej lub wypychanie innych kontenerów z pamięci podczas normalnego użytkowania. Duże użycie pamięci podręcznej bez opóźnień samo w sobie nie jest powodem do modernizacji.

-15% OFF

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

Single board computer zimaboard2

Odizoluj kolejkowanie operacji pamięci masowej i opóźnienia udziałów sieciowych

Gdy interfejs zatrzymuje się podczas skanowania, odtwarzanie rozpoczyna się powoli albo dyski pozostają całkowicie obciążone, porównaj działanie Jellyfin, gdy pamięć multimediów jest bezczynna, z działaniem podczas aktywnego skanowania. Jeśli biblioteka korzysta z obu typów pamięci, porównaj również lokalny plik testowy z plikiem znajdującym się na udziale sieciowym.

Jellyfin zaleca przechowywanie bazy danych na lokalnej pamięci masowej oraz montowanie udziałów Samba lub NFS bezpośrednio w systemie operacyjnym. wskazówki Jellyfin dotyczące pamięci masowej Jeśli montowanie sieciowe działa wolno lub jest okresowo niedostępne, dodanie procesora albo RAM-u do hosta nie usunie tych opóźnień na ścieżce.

Jeśli wąskie gardło znika po przeniesieniu ścieżki multimediów do szybszego lub bardziej niezawodnego punktu montowania, serwer sam w sobie nie był niewystarczający. Jeśli lokalna pamięć masowa również osiąga nasycenie podczas zwykłych operacji na bibliotece, zasobem wymagającym rozbudowy może być układ pamięci masowej lub liczba operacji wejścia-wyjścia na sekundę.

Wyklucz problem klienta lub sieci, zanim uznasz go za ograniczenie serwera

Powtórz ten sam test multimediów na drugim kliencie w sieci LAN. Jeśli jedno urządzenie buforuje, a drugie bezpośrednio odtwarza ten sam plik, serwer może działać prawidłowo, a pierwszy klient może wymuszać inną ścieżkę kodeka, przepływność lub trasę sieciową.

Jellyfin przechowuje informacje o obsłudze kodeków dla poszczególnych klientów, a nieobsługiwane kodeki lub napisy mogą wymusić konwersję. obsługa kodeków przez klienta Dlatego awarii jednego klienta nie należy uogólniać na wniosek o niewystarczającej wydajności całego hosta.

Przepustowość sieci uznaj za ograniczenie serwera dopiero po potwierdzeniu, że interfejs sieciowy serwera lub łącze nadrzędne osiąga nasycenie przy wielu klientach. Przeciążenie Wi-Fi, zdalna trasa przez dostawcę internetu lub jedno słabe urządzenie końcowe to inny problem, który należy rozwiązać na odpowiedniej warstwie.

Zdecyduj, czy dostroić konfigurację, rozbudować sprzęt czy rozdzielić obciążenie

Najpierw dostrój konfigurację, gdy jeden parametr lub rodzaj obciążenia wyjaśnia objaw: włącz zweryfikowaną akcelerację sprzętową, przenieś kosztowne skanowania poza godziny szczytu, ogranicz zbędne operacje na metadanych albo odizoluj powolne montowanie pamięci masowej. Po każdej zmianie ponownie wykonaj dokładnie ten sam test.

Rozbuduj sprzęt, gdy ten sam cel nadal nie jest osiągany, a nasycony zasób jest jasno określony: procesor w przypadku wymaganych transkodowań programowych, RAM przy utrzymującej się presji na pamięć, szybsza lokalna pamięć masowa przy opóźnieniach bazy danych albo lepsza ścieżka sieciowa przy potwierdzonych ograniczeniach przepustowości. Unikaj jednoczesnej modernizacji wielu zasobów, chyba że test wykazuje kilka niezależnych ograniczeń.

Rozdziel obciążenie dopiero wtedy, gdy pojedynczy host nie jest w stanie niezawodnie obsłużyć łącznego zapotrzebowania usług. Zakończ, gdy po ponownym uruchomieniu test przejdzie przy pierwotnym szczytowym obciążeniu; taki wynik jest mocniejszym dowodem niż jakakolwiek ogólna zasada dotycząca tego, jak wydajny „powinien” być serwer Jellyfin.