Hur många användare och bakgrundsjobb bör en Jellyfin-värd klara av?

Eva Wong är teknisk skribent och händig hemmabyggare på ZimaSpace. Som tekniknörd sedan barnsben med ett brinnande intresse för hemlabb och programvara med öppen källkodspecialiserar hon sig på att göra komplexa tekniska koncept begripliga genom praktiska, praktiska guider. Eva tycker att självhosting ska vara roligt, inte avskräckande. Genom sina handledningar hjälper hon communityn att göra hårdvaruinstallationer mindre mystiska, från att bygga sin första NAS till att bemästra Docker-containrar.

En Jellyfin-värd ska inte dimensioneras enbart utifrån antalet registrerade användare. Ett hushåll med åtta konton kan skapa mindre belastning än två fjärranvändare som transkodar 4K-video medan en biblioteksgenomsökning, en undertextuppgift och en säkerhetskopiering körs i bakgrunden. Den relevanta kapacitetsfrågan är hur mycket samtidig förgrunds- och bakgrundsaktivitet värden klarar innan uppspelning eller administration inte längre uppfyller målen.

Skapa en belastningsbudget som omfattar uppspelningssessioner, omkodningar, schemalagda uppgifter, lagringsaktivitet och tjänster som körs på samma värd. Testa sedan den mest intensiva vanliga överlappningen och sluta öka belastningen när den första delade resursen får bestående köbildning, fel eller märkbara fördröjningar för användarna.

Omvandla användare till uppspelningsbelastningar

Räkna sessioner med Direct Play, remuxning, ljudkonvertering och videotranskodning separat. Jellyfin-klienter rapporterar vilka kodekar, upplösningar, bitfrekvenser och begränsningar de stöder, så två användare som tittar på samma källa kan kräva helt olika arbetsinsatser från servern.

Jellyfins användarpolicy kan också påverka serverbelastningen. De aktuella kontrollerna för användarhantering kan tillåta eller begränsa fjärråtkomst, medieuppspelning, omkodning och internetbitrate per ström. Antalet användare blir därför användbart först när det har översatts till de uppspelningsbehörigheter och lägen som förväntas samtidigt.

Utgå från den mest krävande vanliga kvällskombinationen snarare än det teoretiska maximala antalet konton. Om hushållet vanligtvis har två lokala Direct Play-sessioner och en fjärrkonvertering är det den grundbelastning som värden måste klara utan problem.

Lägg till schemalagda jobb i samma kapacitetsbudget

Jellyfin utför arbete även när ingen trycker på Spela upp. Biblioteksgenomsökningar, nedladdning av undertexter, cache-rensning, pluginuppdateringar, extrahering av kapitelbilder, databasoptimering och uppgifter för genererat material kan pågå samtidigt som någon tittar.

Den aktuella listan över schemalagda uppgifter visar att Jellyfin kan köra genomsökningar, bildextrahering, pluginuppdateringar, databasunderhåll, undertextjobb, cache-rensning och andra jobb i bakgrunden. Pluginer kan lägga till fler uppgifter.

Dimensionera inte servern utifrån ett belastningstest med tyst uppspelning och låt sedan alla tunga uppgifter köras under samma toppbelastning. Flytta först sådana jobb som kan skjutas upp till utanför tittartiden; ta med jobb som måste köras samtidigt i belastningstestet.

Hitta den första delade resursen som får minskad marginal

En värd kan fallera på grund av mediamotorns genomströmning, CPU, minne, SSD-latens, sökbelastning på HDD, nätverksbandbredd eller ett beroende. Fler CPU-kärnor hjälper inte när en fjärruppladdningslänk är mättad, och mer RAM löser inte problemet med en transkodning som det valda grafikkortet inte kan accelerera.

ZimaSpaces analys av Jellyfin-kapacitet på en liten hemmaserver använder samma modell med fokus på arbetsbelastningen: samtidiga krav och den första resursen som blir mättad är viktigare än en gräns för antal konton.

Mät transkodningshastighet, belastning på CPU eller mediamotor, minnestryck, lagringslatens och nätverksgenomströmning under den exakta överlappningen. Den begränsande resursen är den vars belastning ökar i samband med felet och minskar när belastningen tas bort.

Single board computer zimaboard2

Se till att bakgrundsarbete inte förbrukar marginalen för interaktiv användning

Uppspelning har en tidsgräns: nästa segment måste anlända innan klientens buffert töms. En biblioteksgenomsökning kan vanligtvis bli klar senare utan att det påverkar någon. Den skillnaden bör styra schemaläggningen och resurspolicyn.

Reservera tillräckligt med marginal för att en vanlig uppspelningsstart eller sökning ska förbli responsiv medan oundvikligt bakgrundsarbete pågår. Om en databaskörning för optimering eller ett medieanalysjobb orsakar buffring kan du schemalägga det annorlunda eller begränsa jobbet innan du köper en större server.

På en delad värd upprepar du testet medan andra containrar körs. En nedladdare, en fotoindexerare, en säkerhetskopieringstjänst eller en lokal AI-process kan minska Jellyfins kapacitet även om Jellyfins egen arbetsbelastning inte har förändrats.

Använd en arbetsbelastningsmatris i stället för en användargräns

Samtidigt arbete Viktigaste resursen att bevaka Felindikator
Strömmar med direktuppspelning Medialagring + nätverk Läs- eller nätverksköerna växer
Videotranskodningar Mediamotor / CPU + temporärt lagringsutrymme Transkodningshastigheten understiger realtid
Biblioteksgenomsökning CPU + lagring av metadata + mediediskar Lägre svarstid vid bläddring eller uppspelning
Generering av bilder/förhandsvisningar CPU/GPU + skrivningar till lagringsenhet Interaktiv arbetsbelastning får mindre marginal
Säkerhetskopiering eller import Lagring + nätverk I/O-konkurrens eller mättad uppladdning

Beskriv kapaciteten utifrån en testad arbetsbelastning, till exempel ”tre representativa strömmar plus en schemalagd genomsökning håller sig inom målet”, inte ”den här servern stöder tio användare”. Resultatet går att återskapa när biblioteket, klienterna och hushållets användning förändras.

Installation av NAS och server

Mer att läsa

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.