Vilken minnesgräns bör du ange för Jellyfin?
Välj inte en universell minnesgräns för Jellyfin; börja med en uppmätt arbetsbelastning, reservera minne för värdsystemet och närliggande containrar och sätt en hård gräns först efter att du har observerat verkliga toppar.
Växer din container tills värdsystemet börjar använda växlingsutrymme, eller orsakar en låg gräns upprepade OOM-avslutningar? Mät viloförbrukning, biblioteksskanningar, metadatabearbetning, samtidiga omkodningar och mängden minne som är tillgänglig för Docker eller den virtuella maskinen innan du ändrar gränsen. En gräns är säker endast när den ursprungliga arbetsbelastningen fortfarande slutförs och värdsystemet har en återhämtningsmarginal.
Skilj normal cachningstillväxt från belastning på resident minne
Jämför först containerns RSS, cache, växlingsutrymme och värdsystemets lediga minne under vila och under det mest krävande återupprepningsbara jobbet. Filsystemcache kan se omfattande ut utan att vara en läcka, medan växande resident minnesanvändning tillsammans med OOM-händelser tyder på en verklig begränsning.
En grundläggande Docker-distribution av Jellyfin startar vanligtvis på några gigabyte och behöver mer för omkodning, men det korrekta värdet beror på arbetsbelastningen (arbetsbelastningsbaserad minnesgrundnivå).
Om RSS förblir stabilt medan cachen växer och värdsystemet har minne som kan frigöras bör du övervaka i stället för att sänka gränsen. Om RSS ökar tillsammans med växlingsanvändning eller OOM-avslutningsmeddelanden fortsätter du med testerna av omkodning och bibliotek.
Testa gränsen under den utlösare som orsakar felet
Kör en biblioteksskanning, en representativ omkodning och det förväntade antalet samtidiga strömmar medan du loggar cgroup-minnesanvändning, minneshändelser, växlingsanvändning och belastning på värdsystemet. Ändra endast minnesgränsen mellan körningarna.
En gräns som klarar uppspelning i vila men misslyckas under undertexter, HDR-konvertering eller indexering är inte en giltig produktionsinställning. Notera vilken utlösare som orsakade felet så att du inte höjer gränsen för en orelaterad flaskhals.
Om containern avslutas höjer du gränsen först efter att ha minskat onödig omkodningscache eller separerat tunga jobb. Om värdsystemet självt börjar använda växlingsutrymme bör du minska samtidigheten eller flytta en roll; att ge Jellyfin allt återstående RAM-minne flyttar bara felet till en annan tjänst.
Sätt en stoppgräns och verifiera att den består
Ha en mjuk varning under den hårda gränsen och lämna tillräckligt med minne för värdsystemet, lagringstjänster och en ren omstart. En hård gräns ska skydda värdsystemet, inte dölja en process utan övre gräns eller en underdimensionerad maskin.
Efter att du har ändrat gränsen stoppar och återskapar du containern en gång och upprepar sedan den ursprungliga skanningen och uppspelningstestet. Kontrollera att den konfigurerade gränsen fortfarande är aktiv efter återskapandet och att databasen fortfarande är skrivbar.
Sluta finjustera och eskalera när OOM-händelser fortsätter vid en gräns som lämnar värdsystemet utan marginal, databasen blir korrupt eller processen växer utan en reproducerbar arbetsbelastning. Spara loggar och den senast fungerande konfigurationen innan du gör en större ändring.
Kontrollera toppbelastningen vid uppspelning igen efter en kall omstart
Starta om värdsystemet, vänta på lagringsmonteringar och närliggande containrar och återskapa samma mix av samtidiga användarströmmar som ursprungligen blottlade gränsen. Validera inte enbart med en inaktiv instrumentpanel eller en enda Direct Play-session.
Återhämtningen är bevisad när uppspelningen förblir stabil, ingen intensiv växlingsanvändning uppstår, containern håller sig under sin gräns och en ny säkerhetskopia eller omstart slutförs utan minnesrelaterade fel. Jämför resultatet med baslinjen som registrerades före finjusteringen.
Behåll inställningen när toppbelastningen klaras med en mätbar marginal för värdsystemet. Om det endast uppstår fel efter att en annan container startar bör du dela upp resursbudgeten eller schemalägga om det konkurrerande jobbet i stället för att höja Jellyfins gräns igen.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Jellyfin-databasanslutningar för samtidiga containrar
Börja med en enda databasägare och mät SQLite:s låsbeteende; lägg till en annan backend först när samtidighet och återställning motiverar komplexiteten.
Så förhindrar du dubbla jobb eller importer i Jellyfin
Dubblet arbete beror vanligtvis på överlappande schemaläggare eller mer än en skrivande komponent; utse en ansvarig, en väg och en kontroll av att arbetet...
Så reparerar du Jellyfin när dess databasvolym blir full
Stoppa skrivningar, bevara databasen och WAL-filerna, frigör utrymme utan att blint radera tillstånd och verifiera sedan integriteten och den ursprungliga arbetsbelastningen.
