Hur mycket ledigt lagringsutrymme bör Plex behålla för bakgrundsjobb?
Plex bör inte använda en enda universell regel för ledigt utrymme på alla servrar. Den användbara reserven är den mängd som behövs för ditt största normala tillfälliga jobb, förväntad tillväxt av metadata samt tillräckligt med extra utrymme för att slutföra underhåll eller återställa efter en misslyckad ändring utan att fylla filsystemet.
En server som bara använder Direct Play för ett litet bibliotek har en annan lagringsprofil än en som genererar förhandsvisningsminiatyrer, omkodar flera strömmar, kör DVR-arbete eller bygger om metadata. Mät först en hel bakgrundscykel och den största representativa omkodningen. Sätt sedan en gräns över den observerade toppen i stället för att kopiera en godtycklig regel på 10 %, 20 GB eller 100 GB.
Börja inte med ett universellt tal för ledigt utrymme
Råd om ledigt utrymme blir missvisande när de bortser från var Plex skriver tillfälliga och beständiga data. En server kan ha terabyte ledigt på medielagringen medan det mindre system- eller appdatafilsystemet får slut på utrymme under en konvertering eller ett underhållsjobb.
Plex dokumenterar att omkodning använder tillfällig disklagring, som som standard kan finnas på operativsystemets disk. Därför är det viktigare att kontrollera det faktiska omkodningssökvägens lediga utrymme än den angivna kapaciteten för medielagringen.
Se alla fasta tal för ledigt utrymme som en första hypotes, och använd dem bara om de har mätts för din arbetsbelastning. Den första användbara gränsen är den minsta reserv under vilken ditt eget bakgrundsarbete blir opålitligt, inte ett tal som hämtats från ett annat bibliotek, en annan bithastighet eller ett annat filsystem.
Mät vilka Plex-jobb som faktiskt förbrukar tillfälligt eller beständigt utrymme
Övervaka de platser som kan växa när Plex är inaktivt eller utför underhåll: appdatakatalogen, den tillfälliga omkodningskatalogen, data för förhandsvisningsminiatyrer, säkerhetskopior av databasen samt eventuella arbetskataloger för nedladdningar eller DVR som du faktiskt använder. De kan finnas på olika filsystem, så mät dem separat.
Förhandsvisningsminiatyrer för video kan vara en källa till beständig tillväxt snarare än en kortvarig topp. Plex uppger att ett typiskt miniatyrindex kan förbruka tiotals megabyte för ett enda biblioteksobjekt, där längden påverkar resultatet. Stora bibliotek kan därför omvandla en liten kostnad per objekt till en betydande tillväxt av appdata.
Mät före och efter ett helt schemalagt underhållsfönster, en biblioteksskanning som lägger till representativt medieinnehåll samt din största normala omkodning. Registrera både den största tillfälliga ökningen och vad som finns kvar efteråt. Den kvarvarande ökningen är tillväxt; toppen över den är arbetsutrymme.
Använd det största observerade jobbet för att sätta den första gränsen
Använd den största observerade ökningen av arbetsutrymmet som den första delen av din gräns. Om en representativ omkodning behöver flera gigabyte på sitt tillfälliga filsystem, eller om ett underhållsfönster ökar mängden appdata när miniatyrer genereras, ska den observerade toppen ingå i reserven.
Anta inte att RAM-baserad omkodning eliminerar kapacitetsfrågan. En praktisk Plex-konfiguration för RAM-omkodning kräver fortfarande att den tillfälliga omkodningskatalogen har tillräcklig användbar kapacitet för den aktiva arbetsbelastningen. När sökvägen flyttas ändras den resurs som måste dimensioneras, men det tillfälliga utrymmet försvinner inte.
För planering kan du definiera en uppmätt gräns som: största normala tillfälliga topp + förväntad kvarvarande tillväxt fram till nästa rensning + en säkerhetsmarginal för variation. Detta är en operativ formel, inte ett konstant värde som Plex har publicerat. Räkna om den efter att du har aktiverat funktioner som väsentligt förändrar bakgrundslagringen.
Lägg till marginal för samtidiga jobb och återställning
Ett jobb i taget är inte värsta scenariot om din server vanligtvis kör överlappande uppgifter. Ett miniatyrjobb, databasunderhåll, en säkerhetskopiering, en nedladdning eller en omkodning kan dela samma filsystem, och en uppgradering kan tillfälligt kräva extra utrymme för en ny avbild eller en återställningskopia.
Lägg till tillräcklig marginal för att den största realistiska överlappningen ska kunna slutföras utan att filsystemet pressas till sin felgräns. Om två jobb aldrig överlappar eftersom du schemalägger dem separat behöver du inte summera deras toppar. Om de ofta överlappar bör du i stället mäta det kombinerade fönstret.
Håll återställningsutrymme åtskilt från mediebibliotekets kapacitet i planeringen. Ett fullt mediebibliotek och en full appdatadisk orsakar olika fel. Behåll tillräckligt med utrymme på filsystemet som innehåller Plex-tillståndet för att skapa en säkerhetskopia, skriva tillfälliga filer och återställa efter en misslyckad underhållsändring.
Var uppmärksam på symtom på lågt utrymme innan disken blir full
Lågt ledigt utrymme visar sig vanligtvis genom åtgärder som kräver nya skrivningar: konverteringar vägrar starta, bakgrundsarbete slutförs inte, databaser eller loggar kan inte utökas eller så börjar operativsystemet rapportera ett nästan fullt filsystem. Vänta inte tills noll byte återstår innan du behandlar utvecklingen som ett kapacitetsproblem.
Plex-användare har återskapat fel vid inspelning eller konvertering när en begränsad tillfällig plats fylls under ett jobb. Därför kan en liten RAM-disk eller apppartition få slut på utrymme även när medielagringen har gott om kapacitet: skrivningen måste lyckas på det filsystem som Plex faktiskt använder för åtgärden.
När ett jobb misslyckas ska du registrera det lediga utrymmet och sökvägen vid exakt den tidpunkten. Om samma jobb lyckas efter att den tillfälliga sökvägen har flyttats eller kapaciteten utökats, medan övriga förhållanden är oförändrade, har tröskeln för ledigt utrymme blivit ett belägg i stället för ett antagande.
Höj gränsen när Plex inte kan slutföra en hel underhållscykel
Genomför mätningen under en hel underhållscykel och en representativ period med intensiv uppspelning. Följ den lägsta punkten för ledigt utrymme, vilket jobb som orsakade den och om filsystemet återgick till en stabil grundnivå efteråt. Upprepa mätningen en gång så att en ovanlig engångsuppgift inte definierar den permanenta reserven.
ZimaSpaces guide om belastning på bakgrundslagringen är en användbar fortsättning när skanningar, säkerhetskopieringar eller andra jobb konkurrerar med Plex om diskresurser. Kapacitet och I/O-prestanda bör kontrolleras tillsammans när underhållsfönstret blir både långsamt och utrymmeskrävande.
Höj gränsen för ledigt utrymme eller flytta arbetsbelastningen när normala jobb upprepade gånger närmar sig den aktuella reserven, när kvarvarande metadatatillväxt stadigt minskar marginalen eller när återställningsåtgärder inte längre får plats. Den rätta gränsen är den som låter den mest intensiva förväntade cykeln slutföras och fortfarande lämnar en testad väg för återställning.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
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.
