Ja, Plex kan ofta dela ett GPU med en annan Docker-container, men att exponera samma enhet för båda containrarna reserverar eller garanterar inte prestanda för någon av arbetsbelastningarna.
Beslutet beror på GPU:n, Linux-drivrutinen, containerns runtime, typen av arbetsbelastning och hur varje program använder videoenheter, beräkningar och minne. Intel-integrerad grafik exponeras vanligtvis via Linux-enhetsnoder som /dev/dri, medan NVIDIA-containrar använder NVIDIA:s container-runtime eller Dockers GPU-reservationer. Konfigurera åtkomsten först, kör sedan Plex och den andra arbetsbelastningen tillsammans och verifiera att Plex fortfarande hårdvarutranskodar under den belastning du faktiskt bryr dig om.
Bekräfta först att Plex kan använda GPU:n på egen hand
Innan du testar delning kör du en tvingad Plex-transkodning med den andra GPU-arbetsbelastningen stoppad. Plex bör rapportera hårdvaruacceleration för strömmen, och värdsystemet bör visa förväntad aktivitet i videoenheten eller GPU:n. Om Plex inte kan använda enheten på egen hand blir felsökningen bara mer otydlig när du lägger till ytterligare en container.
Plex guide för hårdvaruaccelererad strömning förklarar att Docker-distributioner måste exponera den relevanta kärnenheten för containern för att hårdvaruacceleration ska fungera. Använd den aktuella enhetsmetoden för din plattform i stället för att anta att en GPU som upptäcks av värdsystemet automatiskt är synlig i Plex.
Notera starttiden för transkodningen, CPU-användningen, GPU-/videoenhetsanvändningen och uppspelningsstabiliteten som baslinje. Det ger dig ett kontrollresultat för delningstestet. Utan en ren baslinje kan du inte avgöra om senare fel beror på konkurrens om resurser eller på den ursprungliga GPU-konfigurationen för Plex.
Exponera samma enhet medvetet för den andra containern
För NVIDIA kan Docker Compose reservera GPU:er per antal eller enhets-ID för en tjänst. Om två tjänster konfigureras för att se samma GPU kan runtime-miljön exponera den enheten för båda, men detta är åtkomstkontroll och inte ett avtal om exklusiv prestanda. För Intel eller andra Linux-enheter kan båda containrarna få åtkomst till samma relevanta enhetsnod när drivrutinen tillåter samtidig användning.
Dockers dokumentation om GPU-stöd i Compose visar hur tjänster begär GPU-åtkomst och riktas mot specifika enhets-ID:n. Använd en specifik enhet om du har flera GPU:er, så att Plex inte i tysthet växlar mellan enheter medan du testar delning.
Kontrollera behörigheterna efter varje återskapande av containern eller ändring av appmallen. Att den andra containern fungerar bevisar inte att Plex fortfarande har åtkomst till enheten, och att en Plex-inställning visar att hårdvaruacceleration är aktiverad bevisar inte att den aktiva strömmen använder den.
Testa båda arbetsbelastningarna tillsammans och övervaka den första resursen som når taket
Starta den andra arbetsbelastningen på en representativ nivå och tvinga sedan fram samma Plex-transkodning som användes för baslinjen. Jämför uppspelningsstabilitet, transkodningshastighet, GPU-minne, användning av videoenheten och eventuell CPU-fallback. Om Plex växlar från hårdvara till programvara eller börjar buffra först när den andra arbetsbelastningen är aktiv, har du konstaterat resurskonkurrens snarare än ett oförklarligt kompatibilitetsproblem.
ZimaSpaces guide för GPU-förkontroll rekommenderar att du inte bara verifierar enhetsidentifiering, utan även containeråtkomst och om lagring, säkerhetskopieringar och medieuppgifter fortsätter att svara under den kombinerade arbetsbelastningen. Det systemövergripande testet är särskilt viktigt på en NAS där Plex inte är den enda tjänsten som spelar roll.
Om arbetsbelastningarna använder olika GPU-enheter kan delning fungera bra. Om båda konkurrerar om samma videoencode-/videodekodenheter, minne eller effekt- och temperaturmarginaler kan prestandan försämras kraftigt. Anta inte att en låg total ”GPU-procent” betyder att den specifika videoenhet Plex behöver är ledig.
Fastställ när delning inte längre är ett bra alternativ
Behåll den delade konfigurationen om Plex fortsätter att använda hårdvaruläge, den andra containern når sitt mål och NAS:en förblir responsiv under den kombinerade belastningen. Upprepa testet efter en omstart av Plex och efter att den andra containern startats om, så att enhetsmappningar och behörigheter överlever normala livscykelhändelser.
Om resurskonkurrensen bara uppstår ibland kan du schemalägga den tunga andra arbetsbelastningen utanför perioder med högst strömningstrafik eller lägga till begränsningar på programnivå. Om båda arbetsbelastningarna måste köras med full belastning samtidigt och den ena konsekvent svälter den andra på resurser, bör du tilldela en andra accelerator eller flytta den ena arbetsbelastningen till en annan värd i stället för att försöka finjustera sköra prioriteringar.
Gå vidare till felsökning av drivrutin eller runtime när någon av containrarna förlorar GPU:n även när den andra är stoppad. Ett delningsproblem bör diagnostiseras först efter att båda programmen kan få åtkomst till enheten var för sig och felet uppstår specifikt vid samtidig användning.
Support och tips
Mer att läsa

Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.

Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.

Så säkerhetskopierar du Plex utan att fånga en inkonsekvent databas
Använd Plex databassäkerhetskopiering för kärntillståndet, eller stoppa Plex innan du kopierar hela appdataträdet. Testa sedan att återställningen fungerar i stället för att lita på...

