Dlaczego Plex zużywa więcej pamięci GPU przy jednoczesnym korzystaniu z różnych klientów?

Eva Wong

IceWhale author

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.

Why Does Plex Use More GPU Memory Under Mixed-Client Concurrency? - Zima Store Online

Plex wykorzystuje więcej pamięci GPU przy jednoczesnej obsłudze mieszanych klientów, gdy równoczesne sesje wymagają pozostawienia w pamięci różnych zestawów roboczych do dekodowania, transformacji i kodowania.

Najważniejszą zmienną nie jest po prostu liczba widzów. Konwersja 1080p H.264, konwersja 4K HEVC HDR oraz sesja Direct Play mogą jednocześnie korzystać z zupełnie różnych ścieżek GPU. Trafna diagnoza polega na oddzieleniu presji na pamięć wideo od przepustowości kodera, awaryjnego użycia CPU oraz ograniczeń pamięci masowej lub sieci, zanim uzna się VRAM za wąskie gardło.

Mieszani klienci tworzą różne zestawy robocze GPU

Flota mieszanych klientów zmienia to, co Plex musi utrzymywać w gotowości dla każdej aktywnej sesji. Jeden telewizor może akceptować oryginalny obraz HEVC, inna przeglądarka może wymagać wyjścia H.264, a telefon korzystający z ograniczonego łącza zdalnego może żądać niższej rozdzielczości. Sesje nie zużywają więc zasobów GPU jako identyczne kopie tego samego obciążenia.

Gdy wymagana jest konwersja wideo, Plex potrzebuje obsługi dekodowania i kodowania właściwej dla danego kodeka, a także buforów na klatki pośrednie. Dokładna ścieżka sprzętowego dekodowania i kodowania wideo zmienia się w zależności od kombinacji źródła i wyjścia, dlatego dwie sesje o tej samej nominalnej rozdzielczości mogą powodować różne zużycie pamięci.

Direct Play jest przydatnym przypadkiem kontrolnym, ponieważ nie wymaga od serwera dekodowania i ponownego kodowania wideo. Jeśli pamięć GPU rośnie dopiero wtedy, gdy jeden klient przechodzi z Direct Play na transkodowanie sprzętowe, dodatkowa alokacja należy do ścieżki konwersji, a nie do samej równoczesności.

Rozdzielczość i kodek zmieniają rozmiar powierzchni klatek

Pamięć wideo służy do czegoś więcej niż przechowywania skompresowanego pliku odczytywanego z pamięci masowej. Sprzętowe dekodery i kodery pracują z powierzchniami zdekodowanych obrazów, klatkami referencyjnymi oraz pośrednimi buforami wyjściowymi, których rozmiar zmienia się wraz z rozdzielczością, głębią bitową, formatem chroma i działaniem kodeka. Klatka 4K wymaga więc większego zestawu roboczego niż klatka 1080p, jeszcze zanim uwzględni się równoczesność.

4K HEVC może wymagać więcej VRAM niż AVC 1080p w niektórych obciążeniach Plex HDR. Należy traktować to jako wskazówkę dotyczącą obciążenia, a nie stały wzór zużycia pamięci na strumień, ponieważ wersje sterowników, ścieżki mapowania tonów, architektura GPU i wydania Plex mogą zmieniać dokładną alokację.

Wniosek diagnostyczny jest prosty: porównaj tę samą liczbę sesji, zmieniając wyłącznie klasę źródła. Jeśli dwie konwersje 1080p działają bez problemu, ale zastąpienie jednej z nich materiałem 4K HEVC powoduje znaczny wzrost użycia pamięci, powierzchnie związane z rozdzielczością i kodekiem są częścią przyczyny.

Mapowanie tonów i etapy transformacji dodają kolejną warstwę pamięci

Konwersja może obejmować więcej niż dekodowanie jednego formatu i kodowanie innego. Skalowanie, konwersja kolorów, mapowanie tonów HDR do SDR oraz nakładanie napisów mogą wprowadzać pośrednie powierzchnie, które współistnieją z buforami dekodera i kodera. Etapy te mają największe znaczenie, gdy różni klienci wymagają różnych wyjść z tej samej biblioteki.

W kontenerze węzły urządzeń renderujących używane do sprzętowej obsługi wideo muszą być dostępne dla Plex, zanim odczyty pamięci GPU będą miarodajne. Jeśli nie są, awaryjne użycie CPU może sprawić, że zużycie VRAM będzie wyglądało na niskie, podczas gdy kosztowne operacje zostały przeniesione gdzie indziej.

Niski odczyt VRAM przy wysokim użyciu CPU należy traktować najpierw jako problem weryfikacji ścieżki, a nie jako dowód niewykorzystania GPU. Ta sama zasada działa w odwrotną stronę: wysoki poziom zajętości pamięci GPU przy prawidłowej szybkości transkodowania może oznaczać normalne utrzymywanie danych w pamięci, a nie problem z jej pojemnością.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Równoczesność ma znaczenie, gdy te zestawy robocze nakładają się na siebie

Każda sesja transkodowana sprzętowo utrzymuje własny aktywny stan dekodowania i kodowania przez cały czas odtwarzania. W przypadku mieszanych klientów stany te mogą się różnić i pozostawać aktywne jednocześnie, dlatego całkowite zużycie pamięci GPU może rosnąć szybciej, niż sugerowałaby prosta liczba widzów. Nakładanie się obciążeń staje się ważniejsze, gdy kilku użytkowników w krótkim czasie przewija, rozpoczyna odtwarzanie lub zmienia jakość.

W jednym zmierzonym zestawie z kartą GTX 1660 Ti pojedyncze transkodowanie 4K wykorzystywało około 600 MB pamięci GPU. To ograniczony przykład mierzalnego utrzymywania danych w pamięci, a nie zalecana ilość VRAM dla każdego strumienia 4K.

Użyj najbardziej wymagającej wiarygodnej kombinacji zamiast uruchamiać w pętli identyczne pliki testowe. Obciążenie powinno obejmować kodeki, stany HDR, jakość wyjściową i klientów faktycznie używanych w domu, ponieważ właśnie mieszana równoczesność sprawia, że szacunki oparte na identycznych strumieniach są mało miarodajne.

Oddziel presję na pamięć od innych ograniczeń GPU

VRAM może być pełny, gdy koder nadal dysponuje przepustowością, albo może pozostać dużo wolnej pamięci, gdy etap kodeka, limit sesji, ścieżka sterownika lub operacja wykonywana wyłącznie przez CPU nie nadąża. Quick Sync może obsługiwać wiele transkodowań w odpowiednich obciążeniach, ale nie oznacza to, że pojemność pamięci staje się jedynym ograniczeniem równoczesności.

Obserwuj jednocześnie użycie pamięci GPU, wykorzystanie silnika wideo, szybkość transkodowania, użycie CPU i odtwarzanie. Presja na pamięć jest prawdopodobna, gdy nowe lub cięższe sesje zaczynają się nie powodzić w miarę zbliżania się alokacji do limitu urządzenia, podczas gdy pozostałe elementy ścieżki działają prawidłowo; wysokie wykorzystanie bez takiego wzorca wskazuje na inne źródło problemu.

W przypadku całej ścieżki serwera użyj sprawdzonej konfiguracji serwera Plex 4K jako punktu odniesienia dla obsługi kodeków, dostarczania danych z pamięci masowej i akceleracji sprzętowej. Pamięć GPU jest jednym z elementów tego układu, a nie samodzielną specyfikacją liczby obsługiwanych strumieni.