Jellyfinのピーク時に備えて、CPUリソースをどれくらい確保しておくべきですか？

Direct Play、ハードウェアトランスコード、字幕の焼き付け、ソフトウェアフォールバック、ライブラリ処理、同居するコンテナではCPUの使い方が大きく異なるため、Jellyfinに共通するCPU余力の割合はありません。

混在するホームサーバーでは、通常の中で最も負荷が高い持続期間に、CPU全体の約20～30%をアイドルとして確保するのが、Jellyfinの要件ではないものの、妥当な初期目安です。本当に確認すべき条件は、短時間のバーストでキュー待ちが発生しないこと、必要な場面でトランスコード速度がリアルタイムを安全に上回ること、コア単位のホットスポットが抑えられていること、通常のバックグラウンド処理が重なってもフォアグラウンドの応答性が安定していることです。

アイドル状態のダッシュボードではなく、通常時の最悪の組み合わせを測定する

家庭で実際に想定されるピーク負荷を作ります。互換性が最も低いクライアント、必要な字幕またはHDRの処理経路、予想される同時セッション数、さらに重なる可能性のある通常のバックグラウンドジョブまたは同居コンテナを含めます。実際には発生しない負荷による人工的な過酷テストは、そのワークロードが現実に起こり得る場合にのみ役立ちます。

CPU使用率だけでは、処理が待たされているかどうかは分かりません。利用率・飽和・エラーの手法では、リソースがどれだけ使用中かだけでなく、需要がキューに並んで待機しているかも確認します。Jellyfinでは、CPU使用率に加えて、ロードまたはプレッシャー、実行可能タスク数、コアごとの使用率、再生遅延、トランスコード速度を確認します。

まずウォーム状態のベースラインを記録し、次にセッションまたはバックグラウンドジョブを一度に1つずつ追加します。余力の要件は、CPUグラフが単に高く見えた時点ではなく、最初に追加した負荷によって測定可能なキュー待ちやリアルタイム期限の未達が発生した時点から始まります。

ソフトウェア処理経路と部分的なアクセラレーション経路には、より多くのCPUを確保する

Direct Play中心のサーバーでは、視聴者が複数いてもCPU負荷が非常に低い場合があります。ソフトウェアによる映像トランスコードは利用可能なコアの大半を消費することがあります。一方、ハードウェアアクセラレーションを使っても、音声変換、字幕レンダリング、フィルター、オーケストレーション、フォールバック処理はCPU上に残る可能性があります。

実際のJellyfinワークロード別にCPU需要を分類したZimaSpaceの分析が、関連するサイジングの境界を示します。コア数が重要になるのは、どの処理段階が汎用コンピュート上に残るのかを把握してからです。

必要なソフトウェアトランスコードだけですでにCPUが飽和近くまで達している場合、平均で名目上10%の余力があっても、2本目のストリーム、字幕の焼き付け、バックグラウンド解析に対する有意義な保護にはなりません。より大きな余裕を確保する、アクセラレーション経路を改善する、難しいメディアを事前変換する、または視聴時間帯に重いバックグラウンドジョブが重ならないようにする、といった対策が必要です。

平均値を信用する前に、コア単位の飽和を確認する

8コアCPUでも、合計使用率は中程度なのに、1～2本のスレッドだけが張り付くことがあります。フィルター、音声処理経路、データベースタスク、または単一スレッド性能の影響を受けやすい処理が、ユーザーに見える遅延を左右する場合には、これが重要です。

合計値と併せて、コアごとの使用率とCPUプレッシャーを確認します。LinuxのCPUプレッシャー指標は、タスクがCPUを待って停止している時間を示します。これは、使用率だけを見るよりもピーク時の診断に役立ちます。キュー待ちが少なければ平均使用率が高くてもバッチ処理には問題ない場合がありますが、平均値が低くても重要なスレッドが1本飽和すると、映像のカクつきやナビゲーションの遅延が発生することがあります。

1本のホットスレッドを解決するために、ワークロードが活用できるか確認せず、低速なコアを多数搭載したCPUへ交換するのは避けてください。ボトルネックが特定のソフトウェアフィルターやフォールバック経路にあるなら、ベンチマーク上の合計スコアを上げるより、再生経路を変更するほうが実効的な余力を生む場合があります。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

合格基準としてトランスコード速度とフォアグラウンドの遅延を使う

トランスコードが必要なセッションでは、持続的なサンプル期間にわたって処理速度を確認します。ストリームがリアルタイム付近を推移している場合、まだ再生がバッファリングしていなくても、計算上の余裕はほとんどありません。シーンの複雑さ、温度変化、競合する処理を吸収できるよう、持続的な速度がリアルタイムを十分に上回る状態を目指します。

Direct Playやライブラリの閲覧では、ピーク時の組み合わせを実行しながら、初回フレームの表示時間、シークへの応答、API遅延、タスクの所要時間を測定します。持続的な余力を最初に失うリソースに関するZimaSpaceの分析は、同じリソースが同じユーザー向け障害に繰り返し先行する場合にのみ容量を増やす、という有用な停止基準を示しています。

CPU使用率が高くても、トランスコード速度、遅延、プレッシャーが安定しているなら、マシンは単に利用可能な計算資源を効率よく使っているだけかもしれません。プレッシャーが上昇する、トランスコード速度がリアルタイムに近づくまたは下回る、インタラクティブな遅延が急増する、といった場合は、実用上の余力が消費されています。

割合をテスト済みの運用ポリシーに変える

20～30%のアイドル率は、混在サーバーにおける初期運用目標としてのみ使用してください。実証済みのバースト挙動を持つDirect Play中心のマシンでは、これより少なくても安全な場合があります。一方、ソフトウェアトランスコードが家庭内で重要な場合は、さらに大きな余裕が必要になることがあります。

クライアント、コーデック、字幕の利用方法、ハードウェアアクセラレーション、プラグイン、同居サービスを変更した後は、再テストしてください。余力は固定されたCPU仕様ではなく、現在のワークロードの組み合わせによって決まります。