Jellyfinのパフォーマンス、消費電力、復旧性のバランスを取る方法

繰り返し発生する最も厳しい再生経路に合わせて構成を決め、永続的な状態と再構築可能な作業を分離することで、Jellyfinの性能、消費電力、復旧性のバランスを取ります。

スムーズにストリーミングできても復元できないサーバーは不完全です。また、ソフトウェアトランスコードに切り替わる低消費電力のボックスは、セッションのたびにかえって多くの電力を消費することがあります。まず家庭内のワークロードを把握し、演算、ストレージ、ネットワーク、バックアップの役割を割り当てたうえで、実際の再生と再起動の条件で設計を検証します。

余力を追加購入する前に、性能を左右する経路を特定する

ダイレクト再生するクライアント、想定されるトランスコード、字幕の焼き込み、HDRトーンマッピング、リモート再生時のビットレート、バックグラウンドで同時実行するジョブを記録します。ボトルネックとなるのは、メディアの読み込み、デコード、変換、エンコード、ネットワーク配信、クライアントの対応能力のうち、必要な処理経路で最も遅い段階です。

想定される最も厳しいセッションを単独で実行し、同時ストリームを1つずつ増やします。実用的な使用率、飽和、エラーの確認を行うと、高い使用率と、処理余力のないキューとを見分けやすくなります。

電力をトポロジーの制約として扱う

CPUの名称だけで判断せず、アイドル時の消費電力、トランスコード継続時の消費電力、ドライブのスピンアップ動作、冷却時の騒音を比較します。ハードウェアアクセラレーションでCPU負荷を下げられるのは、実際にクライアント側の経路とコーデックの組み合わせが対応している場合に限ります。リモートディスクの待ち時間で高消費電力の状態が続かないよう、アプリケーションのデータベースとトランスコードキャッシュは高速なローカルストレージに置きます。

測定したピーク負荷を、明確な余裕を持って処理できる最小の演算ノードを選びます。容量が主な拡張要因なら、大型のオールインワンシステムを常時稼働させるのではなく、低消費電力のJellyfinホストとストレージノードを分離します。

復旧時に再生処理と競合しないよう、データの役割を分ける

設定とデータベースの状態、代替できないメディア、再構築可能なキャッシュ、バックアップコピー、復旧メディアは、それぞれ別の役割として扱います。ミラーリングは可用性を高めますが、独立したバックアップではありません。バックアップやライブラリのメンテナンス時にI/Oが再生処理と競合する場合は、再生が最も集中する時間帯を避けて実行します。

アプリケーションの状態をクリーンな状態から復元できるか、またデプロイ定義から再構築できるかをテストします。データ役割マップを使えば、復旧可能なデータベースを使い捨てのキャッシュから分離できます。

Featured

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

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

3つの要素のトレードオフを検証する

設計を採用するのは、代表的な再生で遅延とドロップフレームが許容範囲内に収まり、アイドル時と継続負荷時の消費電力が設置環境に適合し、新しいバックアップからサービスを復元できる場合に限ります。測定したワークロードが余裕の範囲を超えたら、ストレージまたはトランスコードの役割を追加して拡張します。新しいワークロードや復旧要件がないのに、根拠のない容量増強しか提案できない場合は、そこで止めます。