Wysokie użycie procesora bezpośrednio po aktualizacji Plexa może być tymczasowym skutkiem migracji lub analizy, ale nie należy bezterminowo uznawać tego za normalne.
Najbezpieczniejsza diagnoza powinna mieć określone ramy czasowe. Zapisz wersję aktualizacji, czas uruchomienia, aktywne procesy Plexa oraz aktywność dysku. Poczekaj na zakończenie wyraźnie wskazanych prac migracyjnych lub analitycznych, a następnie porównaj użycie procesora podczas drugiego, czystego ponownego uruchomienia. Jeśli obciążenie utrzymuje się bez wykonywania tego samego zadania, przejdź od hipotezy „przejścia po aktualizacji” do diagnozowania regresji lub konkretnego obciążenia.
Najpierw sprawdź migrację bazy danych, zanim zmienisz ustawienia
Niektóre wydania Plexa wymagają przeskanowania lub przekształcenia istniejącego stanu bazy danych, zanim serwer będzie w pełni gotowy. Prace te mogą przez ograniczony czas zużywać procesor i powodować operacje wejścia-wyjścia w danych aplikacji.
Niektóre wydania wymagają pełnego skanowania istniejących rekordów bazy danych przed zakończeniem uruchamiania, dlatego tymczasowe użycie procesora i operacje wejścia-wyjścia w danych aplikacji należy oceniać w odniesieniu do zakończenia tej migracji, a nie do normalnego stanu bezczynności.
Sprawdź w logach aktywność migracji i zwróć uwagę, czy użycie procesora spada po przywróceniu gotowości serwera. Nie przerywaj trwającej migracji tylko dlatego, że pierwsze ponowne uruchomienie trwa dłużej niż zwykle.
Odseparuj ponowną analizę od zablokowanego procesu
Aktualizacja może również uruchomić nową lub powtarzaną analizę multimediów, generowanie podglądów albo przetwarzanie metadanych. Takie obciążenie może trwać nawet po udostępnieniu interfejsu internetowego i sprawiać wrażenie regresji serwera.
Analiza po aktualizacji może przez dłuższy czas zużywać procesor; potraktuj zimne i odbudowywane zbiory robocze jako jeden z powodów, dla których zachowanie przy pierwszym uruchomieniu może różnić się od późniejszego stanu bezczynności, podczas gdy ustalasz, które zadanie Plexa faktycznie się wykonuje.
Wstrzymaj opcjonalne zaplanowane zadania lub poczekaj na zakończenie aktywnego zadania, a następnie powtórz tę samą obserwację w stanie bezczynności. Jeśli użycie procesora spadnie, przełóż zadanie na inny termin zamiast zmieniać globalne limity procesora.
Porównaj drugie ponowne uruchomienie
Jednorazowe prace nie powinny identycznie powtarzać się przy każdym czystym uruchomieniu. Drugie ponowne uruchomienie po ich zakończeniu to najszybszy test kontrolny pozwalający odróżnić migrację od trwałego problemu.
Podczas porównania pozostaw ścieżkę danych aplikacji bez zmian i monitoruj te same nazwy procesów oraz metryki. Stała ścieżka danych aplikacji powinna pozostać niezmieniona, aby jedyną celową zmienną była zakończona aktualizacja.
Jeśli podczas drugiego uruchomienia procesor nadal jest maksymalnie obciążony, zbierz logi i ustal, czy obciążenie powoduje wyszukiwanie, skanowanie, transkodowanie czy inny proces. Kontynuuj diagnozę na podstawie konkretnego obciążenia, a nie samej daty aktualizacji.
Wycofuj aktualizację tylko przy bezpiecznym punkcie przywracania stanu
Wycofanie aktualizacji może być ryzykowne, jeśli nowsza wersja zmieniła zapisany stan w sposób niezrozumiały dla starszej wersji. Zabezpiecz bazę danych sprzed aktualizacji, zanim użyjesz wycofania jako skrótu diagnostycznego.
Wycofanie aktualizacji powinno przywracać zgodną kopię stanu, ponieważ czyste punkty przywracania chronią przed zmianami, których starszy plik binarny może nie rozumieć lub nie obsługiwać bezpiecznie.
Gdy wycofanie aktualizacji jest konieczne, przywróć znany, poprawny stan sprzed aktualizacji wraz z odpowiadającą mu wersją. Nie uruchamiaj naprzemiennie starych i nowych plików binarnych na jednej aktywnej bazie danych podczas próby ustalenia przyczyny wysokiego użycia procesora.
Wsparcie i wskazówki
Więcej do przeczytania

Czy Jellyfin może bezpiecznie współdzielić kartę graficzną lub akcelerator z innym kontenerem?
Udostępnianie GPU jest warunkowe: sprawdź widoczność urządzenia i obsługę sterowników, a następnie uruchom oba obciążenia i obserwuj, czy oprogramowanie nie przełącza się na tryb...

Jak sprawdzić, czy błąd Jellyfin pochodzi z klienta, czy z serwera
Błąd Jellyfin należy przypisać klientowi, gdy występuje na jednym urządzeniu; należy go przypisać serwerowi, gdy wiele klientów ulega awarii w tej samej ścieżce, a...

Jak skonfigurować pamięć podręczną i pamięć tymczasową Jellyfin
Oddziel trwałe dane, odbudowywalną pamięć podręczną i tymczasową pamięć na transkodowanie, a następnie zweryfikuj pojemność i uprawnienia za pomocą rzeczywistego testu odtwarzania.

