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

Wąskim gardłem Plexa nie jest wykres o najwyższych wartościach, lecz zasób, którego malejący zapas wydajności wielokrotnie powoduje ten sam objaw podczas odtwarzania lub korzystania z interfejsu.

Rzetelny test zaczyna się od jednego pliku, klienta, trybu odtwarzania i przedziału czasowego, a następnie obejmuje pomiar procesora, pamięci, pamięci masowej i sieci bez zmiany tych warunków. Sama wysoka utylizacja jest słabym dowodem. Zasób staje się głównym wąskim gardłem dopiero wtedy, gdy jego obciążenie rośnie wraz z wystąpieniem objawu, a kontrolowana zmiana dotycząca tego zasobu poprawia pierwotne żądanie.

Napraw jedno powtarzalne obciążenie Plexa

Wybierz najmniejsze żądanie, które odtwarza problem: jeden plik odtwarzany bezpośrednio, który buforuje, jeden transkodowany materiał, za którym system nie nadąża, albo jedną operację na bibliotece, która się zatrzymuje. Nie zmieniaj klienta, wybranych ścieżek, jakości, trasy sieciowej ani równoległych zadań w tle, aby późniejsze pomiary opisywały to samo zadanie.

Skuteczne dochodzenie zaczyna się od objawu, a następnie sprawdza każdy podsystem po kolei. Podobne procedury w systemie Linux również oddzielają obciążenie zasobów, zamiast uznawać jeden wysoki procent utylizacji za odpowiedź.

Zapisuj znaczniki czasu spowolnienia oraz pomiarów, które zbierasz. Jeśli objaw zmienia się lub znika między kolejnymi uruchomieniami, upraszczaj obciążenie, aż stanie się powtarzalne. W przeciwnym razie możesz przypisać skok aktywności dysku z jednego zadania opóźnieniu Plexa spowodowanemu przez inne.

Oddziel obciążenie procesora od obciążenia pamięci

Obciążenie procesora jest najbardziej prawdopodobne, gdy proces Plexa lub transkoder przez dłuższy czas zużywa moc obliczeniową, a wykonywanie pracy pozostaje w tyle. Presja na pamięć wygląda inaczej: ilość dostępnej pamięci spada, rośnie odzyskiwanie pamięci lub pojawia się wymiana, a czas odpowiedzi się wydłuża, nawet gdy procesor nie jest w pełni obciążony.

Narzędzia takie jak top i vmstat pomagają rozróżnić te scenariusze, ponieważ procesor i pamięć wymagają innych wskaźników. Liczbę procesów oczekujących, czas procesora, wolną lub dostępną pamięć, stronicowanie i aktywność wymiany należy analizować w odniesieniu do tego samego zdarzenia w Plexie, a nie jako odizolowane zrzuty ekranu.

Zmieniaj tylko jedną gałąź. Usuń opcjonalne transkodowanie programowe lub włącz sprawdzoną ścieżkę akceleracji, aby przetestować moc obliczeniową; wstrzymaj usługi intensywnie korzystające z pamięci albo tymczasowo zwiększ zapas pamięci, aby przetestować pamięć. Zasób jest potwierdzony dopiero wtedy, gdy pierwotny objaw w Plexie zmienia się w oczekiwanym kierunku.

Sprawdź opóźnienia i przepustowość pamięci masowej przy tym samym żądaniu

Pamięć masowa może być ograniczeniem, nawet gdy pula ma dużo wolnego miejsca. Plex może oczekiwać na odczyt multimediów, metadane, operacje na bazie danych lub obszar roboczy transkodowania, podczas gdy inne zadanie powoduje kolejkowanie. Przydatne porównanie obejmuje dokładnie tę samą ścieżkę multimediów podczas poprawnego i nieudanego działania.

Diagnoza dysku powinna uwzględniać opóźnienia i zachowanie kolejki, a nie tylko przepustowość. Praktyczne monitorowanie operacji wejścia-wyjścia wykorzystuje opóźnienie urządzenia, utylizację i głębokość kolejki, pokazując, czy żądania czekają, nawet gdy podawana w megabajtach na sekundę przepustowość wygląda skromnie.

Wstrzymaj konkurencyjną kopię zapasową lub skopiuj plik testowy do znanej, szybkiej lokalnej ścieżki, nie zmieniając klienta. Jeśli to samo żądanie Plexa zacznie działać poprawnie, a procesor, pamięć i sieć pozostaną na porównywalnym poziomie, podejrzenie dotyczące pamięci masowej zostanie potwierdzone kontrolowanym wynikiem.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Przetestuj sieć niezależnie od serwera

Sesja odtwarzania bezpośredniego może buforować, nawet gdy procesor i pamięć masowa działają prawidłowo, jeśli rzeczywista trasa nie jest w stanie utrzymać wymaganej przepływności multimediów. Jeśli to możliwe, najpierw przetestuj lokalne połączenie przewodowe, a następnie zmierz trasę niezależnie, aby Plex nie był jednocześnie obciążeniem i narzędziem pomiarowym.

Wąskie gardło sieci staje się wiarygodne, gdy spada przepustowość, rośnie liczba utraconych pakietów lub retransmisji albo opóźnienie staje się niestabilne, podczas gdy serwer zachowuje zapas zasobów. Zasób jest bardziej prawdopodobnym wąskim gardłem, gdy obciążenie koreluje z wpływem na działanie, zamiast być oceniane na podstawie jednego zrzutu utylizacji.

Jeśli niezależna trasa przewodowa ma duży zapas przepustowości, a Plex nadal działa nieprawidłowo, wróć do analizy mocy obliczeniowej lub pamięci masowej. Jeśli sama trasa załamuje się w tym samym przedziale czasu, napraw najsłabszy odcinek, zanim zmienisz transkoder, bazę danych lub przydział pamięci.

Zmień jeden podejrzany zasób i powtórz test

Ostatni krok służy rozróżnieniu przyczyny, a nie kolejnemu przeglądaniu panelu. Wybierz zasób, na który wskazują najsilniejsze dowody, i wprowadź jedną odwracalną zmianę, która powinna wpłynąć wyłącznie na tę gałąź: wstrzymaj kopię zapasową, ogranicz konkurencyjny kontener, użyj lokalnego klienta przewodowego albo usuń wymuszoną konwersję.

Tryb odtwarzania Plexa ma znaczenie, ponieważ odtwarzanie bezpośrednie, bezpośredni strumień i transkodowanie stawiają przed serwerem różne wymagania. Ponieważ ścieżka multimediów zmienia się w zależności od zgodności, ten sam plik może przenieść wąskie gardło po zmianie klienta lub jakości.

Powtórz pierwotne obciążenie po wprowadzeniu pojedynczej zmiany i porównaj zarówno objaw, jak i sygnał zasobu. Jeśli potrzebujesz kontynuacji dotyczącej Plexa, test procesora, pamięci, pamięci masowej i sieci wiąże etap naprawy z zasobem, który rzeczywiście zawiódł.