Dlaczego Jellyfin zużywa dużo procesora po aktualizacji?

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.

Wysokie użycie procesora przez Jellyfin po aktualizacji zwykle wynika z jednego z czterech źródeł: pracy wykonywanej podczas uruchamiania lub na bazie danych, zaplanowanych zadań biblioteki, transkodowania programowego lub częściowego albo wtyczki bądź zadania w tle, którego działanie zmieniło się w nowej wersji. Nie zakładaj, że aktualizacja trwale zwiększyła obciążenie Jellyfin, dopóki nie ustalisz, który proces i które zadanie zużywają procesor.

Najszybsza diagnoza polega na porównaniu czasu wystąpienia problemu i rodzaju obciążenia. Jeśli użycie procesora jest wysokie tylko przez kilka minut po uruchomieniu, obserwuj dzienniki uruchamiania i zadań. Jeśli wzrasta tylko podczas odtwarzania, sprawdź aktywny strumień i ścieżkę FFmpeg. Jeśli pozostaje wysokie, gdy nikt niczego nie ogląda, sprawdź zaplanowane zadania i wtyczki. Zmieniaj tylko jedną rzecz naraz, a następnie odtwórz te same warunki, aby odróżnić tymczasowe zadanie po aktualizacji od trwałej regresji.

Oddziel pracę wykonywaną podczas uruchamiania od stałego użycia procesora

Uruchom ponownie Jellyfin w spokojnym okresie i zmierz, jak długo użycie procesora pozostaje podwyższone. Obserwuj dziennik serwera pod kątem migracji, optymalizacji bazy danych, ładowania wtyczek lub komunikatów związanych z biblioteką, a następnie poczekaj, aż interfejs WWW i zaplanowane zadania zakończą pracę, zanim ocenisz nowy poziom bazowy.

Domyślne zaplanowane zadania i zadania wykonywane podczas uruchamiania Jellyfin obejmują skanowanie bibliotek, wyodrębnianie klatek kluczowych, optymalizację bazy danych, czyszczenie pamięci podręcznej oraz aktualizacje wtyczek. Niektóre zadania są uruchamiane także podczas startu, więc skok obciążenia po aktualizacji może oznaczać konserwację, a nie ciągłą zmianę wydajności.

Jeśli po zakończeniu zadań użycie procesora wróci do wcześniejszego zakresu bezczynności, nie dostrajaj transkodowania ani nie wymieniaj sprzętu. Oznacza to, że przyczyną była tymczasowa praca w tle; zamiast tego zaplanuj wymagające zadania poza godzinami oglądania, jeśli zakłócają odtwarzanie.

Sprawdź, czy odtwarzanie nie zaczęło wykorzystywać procesora

Jeśli skok użycia procesora zaczyna się dopiero wtedy, gdy konkretny klient rozpoczyna odtwarzanie, otwórz panel Jellyfin i ustal, czy sesja korzysta z trybu Direct Play, remultipleksowania, transkodowania dźwięku czy transkodowania obrazu. Zmiana klienta lub kodeka może ujawnić programową ścieżkę, która wcześniej nie była używana.

Wymuś odtworzenie tego samego materiału na tym samym kliencie przy wyłączonych napisach, a następnie porównaj użycie procesora. Jeśli obciążenie znacznie spadnie, czynnikiem rozstrzygającym jest ścieżka napisów lub transkodowania. Jeśli podczas Direct Play nadal pozostaje wysokie, sprawdź pamięć masową, wtyczki lub inny proces, zamiast obwiniać enkoder.

Aby dokładniej sprawdzić odtwarzanie, zastosuj tę samą metodę opisaną w artykule sprawdzającym działanie transkodowania sprzętowego: zweryfikuj aktywną ścieżkę GPU/FFmpeg zamiast zakładać, że samo włączenie akceleracji sprzętowej w ustawieniach wystarczy.

Zmierz proces kontenera zamiast zgadywać na podstawie obciążenia hosta

Na współdzielonym serwerze domowym sprawdź, czy to Jellyfin rzeczywiście zużywa procesor. Kopie zapasowe, indeksatory multimediów, klienci pobierania, generatory miniatur i konserwacja systemu plików mogły zostać uruchomione w czasie tego samego ponownego uruchomienia lub aktualizacji.

Środowiska uruchomieniowe kontenerów udostępniają widoki użycia zasobów dla poszczególnych kontenerów; polecenie stats platformy Docker służy do wyświetlania bieżącego użycia zasobów przez działające kontenery. Podczas odtwarzania problemu użyj widoku użycia zasobów według kontenerów lub odpowiednika dostępnego na Twojej platformie.

Jeśli procesor jest zajęty przez inny kontener, wstrzymaj to zadanie i powtórz pierwotny test. Jeśli obciążenie generuje Jellyfin, przejdź do sprawdzania zadań Jellyfin i odtwarzania; jeśli nie, aktualizacja była tylko skorelowana z obciążeniem hosta, a nie była jego przyczyną.

Wyłączaj lub przeplanowuj jedno źródło pracy w tle naraz

Sprawdź stronę zaplanowanych zadań Jellyfin pod kątem zadania, które jest obecnie wykonywane lub wielokrotnie uruchamia się ponownie. Przejrzyj także wtyczki dodające własne zaplanowane zadania, dostawców metadanych, wykrywanie wstępów, przetwarzanie napisów lub inną automatyzację biblioteki.

Nie wyłączaj trwale wszystkich wtyczek i zadań jednocześnie. Wstrzymaj jednego prawdopodobnego kandydata o wysokim koszcie, poczekaj, aż użycie procesora się ustabilizuje, a następnie odtwórz te same warunki bezczynności lub skanowania. Wyraźny spadek obciążenia wskaże daną gałąź; brak zmiany oznacza, że należy ją przywrócić i przetestować kolejnego kandydata.

Jeśli zadanie jest uzasadnione, ale uruchamia się w nieodpowiednim czasie, przeplanuj je zamiast traktować je jako błąd. Jeśli po aktualizacji zapętla się, kończy niepowodzeniem lub natychmiast uruchamia się ponownie, zachowaj dzienniki oraz informacje o wersji wtyczki, zanim zmienisz pliki bazy danych lub przebudujesz serwer.

Potwierdź rozwiązanie przy pierwotnym obciążeniu po aktualizacji

Po ustaleniu przyczyny zastosuj odpowiednią naprawę: pozwól zakończyć migracje, przeplanuj zadanie, przywróć akcelerację sprzętową, zaktualizuj lub wyłącz problematyczną wtyczkę albo skoryguj warunki klienta lub transkodowania. Następnie uruchom Jellyfin ponownie i powtórz dokładnie ten test, który wcześniej powodował wysokie użycie procesora.

Skuteczna naprawa oznacza, że zachowanie procesora ponownie odpowiada obciążeniu: bezczynność stabilizuje się po uruchomieniu, Direct Play pozostaje lekkie, a każde wymagane transkodowanie korzysta z oczekiwanej ścieżki akceleracji. Jedna minuta spokoju bez ponownego wywołania problemu to za mało.

Przejdź do dalszej diagnostyki, gdy wysokie użycie procesora utrzymuje się mimo braku uruchomionych zadań, transkodowania i konkurencyjnego kontenera oraz przy czystej konfiguracji wtyczek. W takiej sytuacji zbierz wersję Jellyfin, system operacyjny i architekturę, stan zadań oraz krótki wycinek dziennika, aby można było zbadać regresję zależną od wersji bez wyciągania wniosków na podstawie jednego obciążonego uruchomienia.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.