最も負荷の高い通常時のトランスコードとバックグラウンド処理が重なる状況でも、CPUが継続的に飽和したり再生が不安定になったりしないよう、Plex用に十分なCPU余力を確保してください。
Direct Play、ソフトウェアトランスコード、ハードウェアアクセラレーション、字幕、スキャン、関連コンテナではCPUの使い方が異なるため、万能な割合はありません。再現可能なピークシナリオを作成し、平均使用率だけでなく飽和状態を測定してください。余力とは、テストしたピーク負荷と、レイテンシーやエラーが発生し始める地点との差です。
最も負荷の高い通常ワークロードから始める
ほとんどのセッションがDirect Playなら、合成的な全コアベンチマークはPlexの実際の負荷を表しません。自宅で実際に重なるストリーム構成、字幕、スキャン、関連サービスを再現してください。
使用率と飽和状態のチェックを使って、CPUが単に忙しいだけなのか、それともピーク時に実行待ちキューが継続的に発生しているのかを確認します。
シナリオを複数回実行し、バッファリング、タスクのレイテンシー、CPUの飽和状態を記録してください。再現可能な通常時の結果のうち、最も悪いものをサイジングの基準にします。
ハードウェアトランスコードとソフトウェアトランスコードを分けて考える
ハードウェアアクセラレーションを使うと、映像変換を汎用CPUコアから切り離せます。一方、ソフトウェアへのフォールバックでは、同じストリームでもはるかに多くのCPUを消費する可能性があります。余力は、実際に発生し得る経路をカバーしなければなりません。
対応するメディアエンジンは、汎用CPUへの負荷を同程度に増やすことなく、複数のトランスコードを処理できます。N100のハードウェアトランスコード結果は、省電力構成の一例です。
最も負荷の高いメディアで、ダッシュボードが意図したハードウェア経路を使用していることを確認してください。フォールバックの可能性がある場合は、余裕が安全だと判断する前に、少なくとも1回はソフトウェアトランスコードのテストを実施します。
ピーク時にバックグラウンド処理を含める
スキャン、分析、バックアップ、別のコンテナは、それぞれ単独では安全な負荷でも、再生中に重なる可能性があります。共有ホストでは、こうした重なりを含むピーク負荷を想定する必要があります。
複数サービスのメディアスタックが同じホストとストレージ経路上で複数のサービスを動かす場合、リソースの同時使用は実際のワークロードの一部です。
一般的なバックグラウンドタスクを1つ実行しながら、最も負荷の高い再生を行ってください。その重なりによって継続的な飽和が発生する場合は、タスクの実行時間を変更するか、より多くの計算リソースを確保します。CPUの飽和、ハードウェアトランスコードからのフォールバック、その他の共有ワークロードのどれが本当の制限要因なのかを把握してから、測定したピーク負荷をPlexのハードウェア要件に反映してください。
決まった割合ではなく、障害発生のしきい値を使う
有用なCPU余力とは、ユーザーに見えるレイテンシーや処理待ちが許容できなくなる地点よりもシステムを低い状態に保てるだけの余裕です。このしきい値は家庭ごとに異なる場合があります。
構成を変更した後に、もう一度飽和状態をチェックすれば、新しい動作点で実際に余裕が回復したかを確認できます。
バッファリングが発生しない、タスクが安定して完了する、CPUキューが継続的に発生しない、といった合格条件を定義してください。ライブラリ、クライアント、コンテナに大きな変更を加えた後は、1つの割合を永久に使い続けるのではなく、再度テストを実施します。
サポートとヒント
もっと読む

Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか?
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。

誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか?
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。

Jellyfinは修理より再構築すべきタイミングとは?
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。

