1台のJellyfinホストでサポートできるユーザー数とバックグラウンドジョブ数は？

Jellyfinホストの性能を、登録ユーザー数だけで決めてはいけません。アカウントが8つある家庭でも、バックグラウンドでライブラリのスキャン、字幕タスク、バックアップを実行しながら、リモート視聴者2人が4K動画をトランスコードする場合より、負荷が低いことがあります。重要なのは、再生や管理が目標を満たせなくなる前に、ホストが同時にどれだけの前景・バックグラウンド処理をこなせるかです。

再生セッション、トランスコード、スケジュールタスク、ストレージの処理、同居するサービスを含めた負荷予算を1つ作りましょう。そのうえで、通常時に最も負荷が重なる状況をテストし、共有リソースに継続的なキューの滞留やエラー、ユーザーが気付く遅延が発生したら、負荷を増やすのを止めます。

ユーザー数を再生負荷に置き換える

ダイレクトプレイ、リマックス、音声変換、動画トランスコードの各セッションを個別に数えましょう。Jellyfinクライアントは、対応コーデック、解像度、ビットレート、制約を報告するため、同じソースを視聴する2人でも、サーバーに要求する処理は大きく異なることがあります。

Jellyfinのユーザーポリシーもサーバーの負荷を変えることがあります。現在のユーザー管理設定では、リモートアクセス、メディア再生、トランスコード、ストリームごとのインターネット帯域幅を許可または制限できます。そのため、ユーザー数が参考になるのは、同時に想定される再生権限と再生方式に置き換えた場合に限られます。

理論上の最大アカウント数ではなく、普段の夜に想定される最も負荷の高い組み合わせから始めましょう。家庭内で通常、ローカルのダイレクトプレイが2セッション、リモート変換が1セッションあるなら、それがホストに余裕をもって処理してもらう基準です。

スケジュール済みジョブを同じ容量予算に含める

Jellyfinは、誰も再生ボタンを押していないときにも処理を行います。ライブラリのスキャン、字幕のダウンロード、キャッシュのクリーンアップ、プラグインの更新、チャプター画像の抽出、データベースの最適化、生成メディア関連のタスクは、視聴中に重なることがあります。

現在のスケジュールタスク一覧には、Jellyfinがスキャン、画像抽出、プラグイン更新、データベースのメンテナンス、字幕処理、キャッシュのクリーンアップなど、さまざまなジョブをバックグラウンドで実行できることが示されています。プラグインによっては、さらにタスクが追加されることもあります。

静かな再生ベンチマークを基準にサーバーの性能を決め、その後、負荷の高いタスクをすべて同じピーク時間帯に実行するのは避けましょう。まず、先送りできるジョブを視聴時間帯の外に移し、重ねて実行する必要があるジョブは本番テストに含めます。

最初に余裕がなくなる共有リソースを特定する

ホストでは、メディアエンジンの処理能力、CPU、メモリ、SSDのレイテンシ、HDDのシーク負荷、ネットワーク帯域、または依存関係が原因で障害が発生することがあります。リモートアップロード回線が飽和している場合、CPUコアを増やしても効果はありません。また、選択したGPUでトランスコードを高速化できない場合、RAMを増やしても解決しません。

ZimaSpaceによる小型ホームサーバーでのJellyfinの処理能力の分析も、同じくワークロードを優先するモデルを採用しています。重要なのはアカウント数の上限ではなく、同時に発生する負荷と、最初に飽和するリソースです。

重複する処理を実行しながら、トランスコード速度、CPUまたはメディアエンジンの飽和度、メモリへの負荷、ストレージのレイテンシ、ネットワークのスループットを測定しましょう。障害とともに負荷が変化し、その負荷を取り除くと改善するリソースがボトルネックです。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

バックグラウンド処理が対話型ワークロードの余裕を使い切らないようにする

再生には期限があります。クライアントのバッファが空になる前に、次のセグメントが届かなければなりません。一方、ライブラリスキャンは、誰にも影響を与えずに後から完了させることができます。この違いを踏まえて、スケジュールとリソースポリシーを決めましょう。

避けられないバックグラウンド処理が続いている間も、通常の再生開始やシークにすぐ応答できるだけの余裕を確保してください。データベースの最適化やメディア分析のジョブでバッファリングが起きる場合は、より大きなサーバーを購入する前に、実行時刻を変更するかジョブに制限を設けましょう。

共有ホストでは、ほかのコンテナも稼働させた状態でテストを繰り返してください。ダウンローダー、写真のインデクサー、バックアップエンジン、ローカルAIプロセスなどが動くと、Jellyfin自体のワークロードが変わっていなくても、処理できる量が減ることがあります。

ユーザー数の上限ではなくワークロードマトリックスを使う

「代表的なストリーム3本とスケジュール設定されたスキャン1件を実行しても目標範囲内に収まる」のように、テストしたワークロードとして処理能力を示しましょう。「このサーバーは10人のユーザーに対応」とするのではなく、ライブラリ、クライアント、家庭内の利用状況が変わっても再現できる結果を示します。