Jellyfinのパフォーマンス、消費電力、復旧性のバランスを取る方法
Jellyfinのパフォーマンス、消費電力、復旧性のバランスを取るには、繰り返し発生する最も負荷の高い再生経路を基準に容量を決め、永続的な状態と再構築可能な作業を分離します。
スムーズにストリーミングできても復元できないサーバーは不完全です。また、低消費電力のボックスがソフトウェアトランスコードに切り替わると、セッションのたびに余計な電力を消費する可能性があります。まず家庭内のワークロードを把握し、コンピューティング、ストレージ、ネットワーク、バックアップの役割を割り当て、実際の再生と再起動の条件で設計を検証しましょう。
余裕を確保する前に、パフォーマンスの経路を定義する
ダイレクトプレイ対応クライアント、想定されるトランスコード、字幕の焼き付け、HDRトーンマッピング、リモート再生時のビットレート、同時実行するバックグラウンドジョブを記録します。制約となる経路は、メディアの読み出し、デコード、変換、エンコード、ネットワーク配信、クライアント性能のうち、必要な段階で最も遅いものです。
想定される最も負荷の高いセッションを単独で実行し、その後、同時ストリームを1つずつ追加します。実用的な利用率、飽和度、エラーの確認により、使用率が高いだけなのか、処理余力のないキューが発生しているのかを見分けられます。
電力をトポロジーの制約として扱う
CPUの名称だけで判断せず、アイドル時の消費電力、トランスコード継続時の消費電力、ドライブのスピンアップ動作、冷却ファンの騒音を比較します。ハードウェアアクセラレーションによってCPU負荷を下げられますが、実際に利用できるのはクライアントとコーデックの組み合わせが対応している場合に限られます。アプリケーションのデータベースとトランスコードキャッシュは高速なローカルストレージに置き、リモートディスク待ちによって高消費電力状態になるのを防ぎます。
測定したピーク負荷を、記録した余裕を保って処理できる最小のコンピュートノードを選びます。増加の主因がストレージ容量である場合は、大型のオールインワンシステムを常時稼働させるのではなく、低消費電力のJellyfinホストとストレージノードを分離します。
再生と復旧が競合しないよう、データの役割を分離する
設定とデータベースの状態、代替できないメディア、再構築可能なキャッシュ、バックアップコピー、復旧メディアを、それぞれ異なる役割として管理します。ミラーリングは可用性を高めますが、独立したバックアップではありません。バックアップやライブラリのメンテナンスによるI/Oが競合する場合は、最も再生が集中する時間帯を避けてスケジュールします。
アプリケーションの状態をクリーンな環境に復元し、デプロイ定義から再構築するテストを実施します。データ役割マップを使うと、復旧可能なデータベースと破棄可能なキャッシュを分離できます。
3つのトレードオフを検証する
代表的な再生が遅延とドロップフレームの許容範囲内に収まり、アイドル時と継続負荷時の消費電力が環境の要件に適合し、最新のバックアップからサービスを復元できる場合にのみ、設計を合格とします。測定したワークロードが余裕を超えた場合は、ストレージまたはトランスコードの役割を追加して拡張します。新たなワークロードや復旧要件がないまま、推測上の容量だけを増やす提案しか残っていないなら、そこで止めます。
おすすめ商品
NAS＆サーバー設定
もっと読む
AIに似た分析と自動化がJellyfinのストレージおよびコンピューティング要件をどう変えるか
自動化と関連するAI分析では、通常のJellyfin再生に加えて、スキャン、派生データ、CPU/GPU処理、キャッシュ、作業用領域、バックグラウンドスケジューリングが追加されます。
小さなアパートや賃貸住宅のネットワークにJellyfinを統合する方法
安定したローカルアドレス、最小限の配線、静音ハードウェア、CGNATを考慮したリモートアクセス、そして元に戻せる変更を軸に、賃貸住宅に適したJellyfinネットワークを構築しましょう。
1台のJellyfinホストでサポートできるユーザー数とバックグラウンドジョブ数はどれくらいですか？
Jellyfinユーザーとバックグラウンドジョブを1つの共有ワークロード予算として扱い、再生遅延、キュー、またはリソース圧迫が繰り返し発生した時点で容量の限界とします。
