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

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

再生セッション、トランスコード、スケジュールタスク、ストレージ処理、同居サービスを含む、1つのワークロード予算を作成します。そして通常時に発生する最も忙しい処理の重なりをテストし、共有リソースのいずれかで持続的なキュー、エラー、またはユーザーが認識できる遅延が最初に発生した時点で負荷の追加を止めます。

ユーザー数を再生ワークロードに変換する

Direct Play、リムックス、音声変換、ビデオトランスコードのセッションは、それぞれ分けて数えます。Jellyfinのクライアントは、対応コーデック、解像度、ビットレート、制約を通知するため、同じソースを視聴している2人のユーザーでも、サーバーに求める処理は大きく異なる場合があります。

Jellyfinのユーザーポリシーもサーバーへの要求を変える可能性があります。現在のユーザー管理コントロールでは、リモートアクセス、メディア再生、トランスコード、ストリームごとのインターネットビットレートを許可または制限できます。したがって、ユーザー数が有用な指標になるのは、同時に想定される再生権限と再生モードへ変換した後だけです。

理論上のアカウント最大数ではなく、通常の夜に発生する最も負荷の高い組み合わせから始めます。家庭で通常、ローカルのDirect Playが2セッション、リモート変換が1つ発生するなら、それがホストが余裕を持って処理できるべき基準です。

スケジュールタスクを同じ容量予算に加える

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

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

負荷の低い再生ベンチマークだけを基準にサーバーを選び、その後、すべての重いタスクを同じピーク時間帯に実行してはいけません。延期可能なジョブはまず視聴時間帯の外へ移し、重なりを避けられないジョブは本番環境のテストに含めます。

最初に余裕を失う共有リソースを見つける

ホストは、メディア処理性能、CPU、メモリ、SSDレイテンシ、HDDのシーク負荷、ネットワーク帯域幅、または依存サービスのいずれかが原因で限界に達する可能性があります。リモートアップロード回線が飽和している場合、CPUコアを増やしても役に立ちません。また、選択したGPUがアクセラレーションに対応できないトランスコードは、RAMを増やしても解決しません。

ZimaSpaceの小型ホームサーバーにおけるJellyfinの容量分析も同じワークロード優先のモデルを採用しています。アカウント数の上限より、同時発生する要求と最初に飽和するリソースが重要です。

正確な処理の重なりが発生している間に、トランスコード速度、CPUまたはメディアエンジンの飽和、メモリ負荷、ストレージレイテンシ、ネットワークスループットを測定します。障害の発生に伴って負荷が変化し、その負荷を取り除くと改善するリソースが、制限要因です。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

バックグラウンド処理にインタラクティブ処理の余裕を使い切らせない

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

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

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

ユーザー制限ではなくワークロードマトリクスを使う

容量は「代表的な3つのストリームと1つのスケジュールスキャンを実行しても目標範囲内に収まる」のように、テスト済みのワークロードとして示します。「このサーバーは10人のユーザーに対応」とするのではありません。この結果なら、ライブラリ、クライアント、家庭内の利用状況が変わっても再現できます。