Jak przełożyć parametry CPU, RAM i IOPS na wydajność Plexa

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.

Kupując sprzęt do Plexa, przełóż parametry CPU, pamięci RAM i IOPS na progi obciążenia zamiast porównywać największe wartości w specyfikacji. Zacznij od ścieżek odtwarzania i usług towarzyszących, które serwer musi obsłużyć, wybierz najniższy wystarczający poziom bazowy i przeprowadzaj ulepszenia dopiero wtedy, gdy zmierzone ograniczenie przekroczy ustalony próg.

Określ obciążenie Plexa przed analizą specyfikacji

Zapisz najbardziej obciążoną realistyczną godzinę: odtwarzanie bezpośrednie, remuksy, transkodowanie wideo, przypadki z napisami, ograniczenia zdalnej przepływności, skanowanie biblioteki i konkurencyjne aplikacje. Oddziel wymagania od opcjonalnego zapasu wydajności. Parametr ma znaczenie tylko wtedy, gdy kontroluje jedną z tych operacji lub zachowuje margines bezpieczeństwa podczas ich nakładania się.

Metodyka doboru zasobów do obciążenia wyjaśnia, dlaczego CPU, pamięć, pamięć masowa i sieć należy dobierać na podstawie różnych sygnałów. Zastosuj tę samą metodę w przypadku Plexa, zamiast sprowadzać decyzję do jednego ogólnego wyniku wydajności.

Warunek zakupu: odrzuć każdego kandydata, którego system operacyjny, ścieżka sterowników lub interfejs sieciowy nie obsługuje wymaganej ścieżki odtwarzania, nawet jeśli jego procesor lub pojemność pamięci wyglądają lepiej na papierze.

Przełóż CPU na możliwości transkodowania programowego i sprzętowego

W przypadku serwera nastawionego przede wszystkim na odtwarzanie bezpośrednie zapotrzebowanie na CPU jest zwykle niewielkie, a zakup dodatkowych rdzeni może nie poprawić odtwarzania. Transkodowanie wideo programowo podnosi wymagania bazowe, natomiast obsługiwane transkodowanie sprzętowe przenosi znaczną część pracy wideo do silnika multimedialnego. CPU nadal obsługuje dźwięk, napisy, pracę biblioteki oraz każdy etap, który przełącza się z akceleracji na tryb programowy.

Praktyczny przewodnik po transkodowaniu sprzętowym pokazuje, dlaczego sama liczba rdzeni nie pozwala przewidzieć możliwości Plexa. Przed uwzględnieniem zapasu na transkodowanie sprzętowe sprawdź kodek źródłowy, głębię bitową, format wyjściowy, mapowanie tonów, napisy i generację akceleratora.

Minimum: najtrudniejsza wymagana sesja musi być konwertowana z szybkością wyższą niż czasu rzeczywistego, z zapasem na zadania niezwiązane z wideo. Ulepsz CPU lub generację silnika multimedialnego dopiero wtedy, gdy odtworzona sesja wysyca bieżącą ścieżkę albo brakuje obsługi wymaganego kodeka.

Przełóż RAM na dostępny zapas zasobów

Pamięć RAM powinna pomieścić system operacyjny, Plexa, pamięć podręczną systemu plików, bazy danych i usługi towarzyszące bez ciągłego użycia pamięci wymiany ani zdarzeń braku pamięci. Mała ilość wolnej pamięci sama w sobie nie oznacza problemu, ponieważ Linux celowo wykorzystuje wolną pamięć jako pamięć podręczną. Przydatnymi sygnałami przy zakupie są dostępna pamięć i presja pamięci w najbardziej obciążonej godzinie.

Wyjaśnienie dotyczące księgowania pamięci w systemie Linux pomaga uniknąć częstego przewymiarowania: dokładania RAM-u dlatego, że dane w pamięci podręcznej sprawiają, iż kolumna wolnej pamięci wygląda na małą. Dobierz rozmiar do zmierzonego zbioru roboczego oraz marginesu na odzyskiwanie zasobów.

Próg rozbudowy: wybierz więcej RAM-u, gdy planowany stos powoduje ciągłą aktywność pamięci wymiany, zastoje wywołane presją pamięci, restarty kontenerów lub brak miejsca na celowo ograniczony obszar roboczy w pamięci. Większa ilość RAM-u nie przyspieszy ścieżki kodeka ograniczonej przez CPU lub silnik multimedialny.

Przełóż IOPS i przepustowość na oddzielne warstwy pamięci masowej

Pliki multimedialne zwykle generują duże odczyty sekwencyjne, dlatego ważne są łączna przepustowość i szybkość sieci. Metadane Plexa, miniatury, indeksy i bazy danych generują mniejsze operacje, w przypadku których opóźnienia i IOPS wpływają na responsywność. Duży dysk z multimediami może zapewniać odpowiednie strumieniowanie, a jednocześnie spowalniać przeglądanie biblioteki, jeśli stan aplikacji współdzieli przeciążoną kolejkę.

Wprowadzenie do pamięci masowej dotyczące IOPS i opóźnień pokazuje, dlaczego jedna reklamowana wartość prędkości nie może reprezentować obu wzorców. Wybierz niezawodną pamięć masową o niskich opóźnieniach dla stanu aplikacji Plexa, a masową pamięć na multimedia dobierz pod kątem pojemności, trwałych odczytów i przyszłego wzrostu.

Próg rozbudowy: kup szybszą warstwę metadanych, gdy opóźnienie małych operacji rośnie podczas skanowania, a przepustowość multimediów pozostaje prawidłowa. Dodaj przepustowość ścieżki multimediów dopiero wtedy, gdy równoczesne strumienie rzeczywiście zbliżają się do trwałego limitu dysku lub sieci.

Ustal, czy pamięć transkodowania zmienia wymagany poziom RAM-u

Katalog transkodowania oparty na dysku wymaga odpowiedniej pojemności, wydajności zapisu, prawidłowych uprawnień i mechanizmu czyszczenia. Katalog oparty na pamięci eliminuje zapisy na dysku, ale rezerwuje lub zużywa systemowy RAM. Ta opcja może uzasadniać wybór większej ilości pamięci, jednak nie należy traktować jej jako obowiązkowej funkcji Plexa.

Praktyczny test transkodowania w RAM-ie pokazuje, dlaczego rozmiar obszaru roboczego należy określać na podstawie obserwowanej liczby równoczesnych sesji. Przewijanie, wysokie przepływności i kilku klientów mogą zmienić tymczasowe zużycie pamięci.

Dyskwalifikacja: nie wybieraj serwera z małą ilością pamięci, zakładając, że nieograniczona ścieżka transkodowania w RAM-ie pozostanie bezpieczna. Zachowaj wystarczającą ilość dostępnej pamięci dla systemu albo użyj obszaru roboczego opartego na dysku i zwiększ pojemność tam, gdzie wymagają tego pomiary.

Użyj listy pomiarów, aby sfinalizować zakup

Przetestuj każdego finalistę, uruchamiając jedno odtwarzanie bezpośrednie, jedno typowe transkodowanie, najtrudniejsze oczekiwane transkodowanie, skanowanie biblioteki oraz najbardziej obciążającą usługę towarzyszącą. Zapisz użycie CPU dla poszczególnych rdzeni, aktywność sprzętowego dekodowania i kodowania, minimalną ilość dostępnej pamięci, zdarzenia użycia pamięci wymiany lub OOM, opóźnienia pamięci masowej, przepustowość oraz stan odtwarzania po stronie klienta.

Pomiary zasobów kontenera zapewniają powtarzalny sposób obserwacji wdrożeń kontenerowych. Gdy Plex jest zainstalowany bezpośrednio, użyj równoważnych metryk hosta.

Wybierz najtańszego kandydata, który przejdzie wszystkie wymagane testy z jasno określonym zapasem. Nie przywiązuj dużej wagi do niewykorzystanej maksymalnej ilości RAM-u, łącznej pojemności biblioteki w terabajtach, szczytowych syntetycznych wartości IOPS ani dodatkowych rdzeni CPU, chyba że zmieniają wynik pomiaru. Przewodnik po specyfikacji NAS dla Plexa pomoże przełożyć zebrane pomiary na ostateczną krótką listę serwerów.

Parametr Dowód wystarczającego minimum Próg rozbudowy
CPU lub silnik multimedialny Najtrudniejsza wymagana ścieżka działa szybciej niż w czasie rzeczywistym Nieobsługiwany kodek lub wysycona ścieżka konwersji
RAM Zbiór roboczy mieści się z zapasem na odzyskiwanie zasobów Pamięć wymiany, presja pamięci, OOM lub ograniczony obszar roboczy w RAM-ie
IOPS i opóźnienia Metadane pozostają responsywne podczas skanowania Opóźnienia małych operacji spowalniają bibliotekę
Przepustowość Równoczesne strumienie pozostają poniżej trwałej przepustowości Zmierzona saturacja ścieżki multimediów lub sieci

Przewodnik zakupowy

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.