Jak sprawdzić, czy Plex jest ograniczany przez procesor, pamięć RAM, pamięć masową czy sieć

Możesz ustalić, co ogranicza Plex, odtwarzając jedno znane obciążenie i obserwując zasób, którego przeciążenie rośnie w tym samym czasie, gdy strumień zaczyna zwalniać. Nie ulepszaj najpierw komponentu, który wygląda na najbardziej obciążony; wysokie wykorzystanie ma znaczenie tylko wtedy, gdy zbiega się z problemem odtwarzania.

Zacznij od jednego pliku, jednego klienta, jednego trybu odtwarzania i jednego przedziału czasowego. Następnie oddziel zadania konwersji Plex od sygnałów systemu operacyjnego dotyczących procesora, pamięci, pamięci masowej i sieci. Test jest zakończony dopiero wtedy, gdy zmiana jednego podejrzanego zasobu zmienia pierwotny objaw Plex, a pozostałe warunki pozostają stabilne.

Odtwórz jedno obciążenie Plex przed odczytem metryk systemowych

Wybierz plik i klienta, które niezawodnie odtwarzają problem. Zapisz, czy objawem jest powolne uruchamianie, powtarzające się buforowanie, transkodowanie, które nie nadąża, skan powodujący opóźnienia odtwarzania, czy problem występujący wyłącznie zdalnie, ponieważ każdy z tych objawów wskazuje inną ścieżkę oczekiwania.

Przepływ rozwiązywania problemów w Plex powinien zaczynać się od aktywnej sesji, a nie od ogólnego wykresu procesora. Praktyczne sprawdzanie oparte na panelu rozdziela gałęzie bezpośredniego odtwarzania, transkodowania, sieci i pamięci masowej, zanim zaczniesz zmieniać konfigurację serwera.

Podczas zbierania metryk systemowych nie zmieniaj pliku, wybranych ścieżek, jakości klienta ani równoczesnego obciążenia. Jeśli objaw zmienia się między testami, upraszczaj obciążenie, aż ta sama awaria będzie się powtarzać; w przeciwnym razie późniejszy skok użycia procesora lub dysku może należeć do innego zadania.

Użyj sesji Plex, aby oddzielić dostarczanie multimediów od konwersji

Odczytaj sesję Plex w czasie występowania problemu. Bezpośrednie odtwarzanie oznacza, że serwer głównie dostarcza zapisane multimedia, natomiast transkodowanie wideo dodaje rzeczywistą ścieżkę konwersji, która może przesunąć wąskie gardło w stronę procesora lub sprzętowych silników wideo.

Traktuj ten tryb jako rozgałęzienie, a nie jako ostateczny wniosek. Transkodowanie, które nie nadąża, czyni moc obliczeniową silnym kandydatem, ale buforowanie podczas bezpośredniego odtwarzania nadal pozostawia w grze pamięć masową i sieć. Jeśli ten sam plik zmienia tryb po zmianie napisów, dźwięku lub jakości, ponownie odtwórz problem z pierwotnym żądaniem, zanim porównasz metryki hosta.

Ten etap kończy się ustaleniem stałego trybu odtwarzania powiązanego z objawem. Jeśli nie potrafisz stwierdzić, czy nieudany test dotyczy bezpośredniego odtwarzania, czy transkodowania, zatrzymaj się tutaj; porównywanie danych dotyczących pamięci RAM, dysku i sieci przed ustabilizowaniem ścieżki multimediów utrudnia interpretację pozostałych metryk.

Testuj obciążenie procesora i pamięci RAM jednocześnie

Podczas ustalonego testu Plex obserwuj wykorzystanie procesora, kolejkę uruchamiania lub obciążenie, dostępną pamięć oraz aktywność wymiany. Presja na procesor jest najbardziej znacząca, gdy proces Plex lub jego transkoder stale zużywa moc obliczeniową, a dane wyjściowe pozostają w tyle; presja na pamięć jest silniejsza, gdy system zaczyna odzyskiwać pamięć lub korzystać z pamięci wymiany, a czas reakcji się pogarsza, mimo że procesor nie jest jedynym obciążonym zasobem.

Ogólny przepływ analizy wydajności Linuksa wykorzystuje narzędzia takie jak top, vmstat, iostat i sar do rozdzielania presji na zasoby. W szczególności procesor, pamięć, dysk i sieć wymagają różnych sygnałów nasycenia, a nie jednej ogólnej wartości wykorzystania.

Jeśli procesor pozostaje blisko limitu wyłącznie podczas nieudanego transkodowania, a strumień odzyskuje płynność po usunięciu lub przyspieszeniu konwersji, uznaj moc obliczeniową za główne wąskie gardło. Jeśli natomiast rośnie użycie pamięci wymiany lub odzyskiwanie pamięci, ogranicz liczbę równoczesnych zadań intensywnie korzystających z pamięci albo dodaj pamięć, a następnie powtórz to samo obciążenie Plex przed zmianą ustawień pamięci masowej lub sieci.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testuj pamięć masową z tą samą ścieżką multimediów

W przypadku pamięci masowej odczytuj te same multimedia z tego samego systemu plików podczas odtwarzania objawu i obserwuj opóźnienia urządzenia, kolejkowanie oraz czas oczekiwania na operacje wejścia-wyjścia. Pojemność i wydajność to odrębne kwestie: dysk może mieć dużo wolnego miejsca, a mimo to odpowiadać powoli, ponieważ inne zadanie generuje losowe operacje wejścia-wyjścia albo ścieżka multimediów przebiega przez obciążoną pulę lub zamontowany zasób sieciowy.

Narzędzia Linuksa, takie jak iostat i iotop, są przydatne, ponieważ czas oczekiwania na operacje wejścia-wyjścia dysku oraz przepustowość urządzenia ujawniają inny tryb awarii niż wysokie użycie procesora lub aktywność pamięci wymiany. Porównuj te wartości z dokładnym momentem buforowania, a nie ze średnią w stanie bezczynności.

Jeśli plik jest odczytywany bez problemów, gdy Plex buforuje, pamięć masowa staje się mniej prawdopodobną przyczyną. Jeśli wraz z objawem rosną opóźnienia i kolejka, wstrzymaj konkurencyjne zadanie dyskowe albo przenieś plik testowy do znanej jako szybkiej lokalnej ścieżki; jeśli Plex natychmiast odzyska płynność w tym samym trybie odtwarzania, pamięć masowa przechodzi od podejrzenia do potwierdzonego dowodu.

Testuj przepustowość sieci na rzeczywistej ścieżce

Przetestuj ścieżkę między serwerem a klientem niezależnie od Plex. Lokalny klient przewodowy może odróżnić problem z trasą zdalną od problemu z zasobami całego serwera, a test przepustowości od końca do końca może pokazać, czy ścieżka jest w stanie utrzymać szybkość transmisji multimediów bez zależności od aplikacji Plex.

Użyj narzędzia takiego jak iperf3, jeśli kontrolujesz oba końce połączenia. Test sieci powinien uwzględniać przepustowość, utratę pakietów i opóźnienia, ponieważ deklarowana szybkość łącza nie dowodzi, że rzeczywista trasa zapewnia stabilny ruch aplikacji.

Jeśli niezależny test sieci załamuje się, a procesor, pamięć i pamięć masowa pozostają w dobrym stanie, napraw ścieżkę przed dostrajaniem transkodera. Jeśli sieć ma wystarczający stały zapas przepustowości, a objaw Plex utrzymuje się podczas przewodowego testu lokalnego, wróć do gałęzi zasobów serwera zamiast kupować szybszy router.

Zmieniaj wyłącznie zasób, który nie przeszedł testu

Wybierz pierwszy zasób, który nie przeszedł testu rozstrzygającego, i wprowadź jedną zmianę, która powinna wpłynąć wyłącznie na tę gałąź. Przykłady obejmują włączenie zweryfikowanego sprzętowego transkodowania dla strumienia ograniczonego mocą obliczeniową, ograniczenie zadania działającego w tle i intensywnie korzystającego z pamięci, przełożenie zadania intensywnie wykorzystującego dysk albo pominięcie słabego odcinka sieci.

W przypadku dalszej diagnostyki Plex ścieżka diagnozowania buforowania w ZimaSpace zapewnia dokładniejszą kontynuację, gdy już wiesz, czy należy zmienić tryb odtwarzania, obciążenie związane z konwersją, stabilność sieci czy szybkość reakcji pamięci masowej.

Po zmianie powtórz test z użyciem pierwotnego pliku, klienta i trybu odtwarzania. Uznaj komponent za wąskie gardło tylko wtedy, gdy pierwotny objaw się poprawi, a odpowiadający mu sygnał presji spadnie lub zyska zapas. Jeśli objaw się nie zmieni, przywróć stan bazowy i przetestuj kolejną gałąź, zamiast dokładać kolejne ulepszenia, aż rzeczywista przyczyna przypadkowo zniknie.