CPU、RAM、IOPSの仕様をJellyfinのパフォーマンスにどう換算するか
仕様はワークロードに照らして読み解きましょう。CPUとメディアエンジンは変換能力を左右し、RAMはOSと同時に実行するサービスを支え、IOPSは映画の読み出しよりも主にJellyfinのアプリデータに影響します。
まず、ストリームがダイレクトプレイか変換かを確認する
ダイレクトプレイでは、基本的に既存のファイルをストレージからネットワーク経由でクライアントへ転送します。この経路では、サーバーが動画を再エンコードしないため、CPUベンチマークのスコアが高くても変化はほとんどありません。重要なのは、ソースの読み出し速度、ネットワークの安定性、そしてファイル形式に対応したクライアントです。
変換が必要な場合は、性能モデルが変わります。Jellyfinでは、動画のデコード、字幕処理やトーンマッピング、拡大縮小またはピクセル形式の変換、出力のエンコードが必要になることがあります。一部の処理は専用メディアハードウェアを利用できますが、対応していない処理はCPUにフォールバックする場合があります。
Jellyfinのトランスコードガイドでは、クライアントの機能と制約によって出力経路が決まると説明されています。したがって、CPUスコアが意味を持つのは、重要なクライアントが実際にどの処理を要求するのかを把握してからです。
CPU仕様は、汎用計算性能とソフトウェアフォールバック能力として読む
CPUは、音声変換、ライブラリ処理、コンテナのオーバーヘッド、ハードウェアアクセラレーションに対応していない動画処理に関係します。コア数やベンチマークスコアは、想定するソフトウェア処理と照らし合わせた場合にのみ有用であり、サーバーが処理できる4Kストリーム数を直接示すものではありません。
Jellyfinのハードウェア選定ドキュメントでは、ソフトウェアによる動画トランスコードやHDRトーンマッピングは非常に負荷が高い一方、対応する動画処理をハードウェアアクセラレーションで処理できる場合、数スレッドを備えた最新のCPUで軽いサーバー業務には通常十分だと説明されています。
新しく購入する場合は、内蔵メディアエンジンをCPUコアとは別の機能として考えましょう。適切にサポートされたメディアエンジンを備えた低消費電力のプロセッサは、対応するトランスコードにおいて、はるかに大型のCPUを上回ることがあります。その場合、CPUは主に処理の制御とフォールバック処理を担います。
RAMは8GBを基準にし、ホスト全体の用途に応じて増設する
Jellyfinは現在、一般的な構成ではシステムRAM 8GBを推奨しており、ヘッドレスLinuxサーバーなら4GBでも十分な場合があるとしています。これは有用な基準ですが、すべてのホームサーバーに共通する目標ではありません。
ホストでデータベース、写真のインデックス作成、ダウンロードツール、仮想マシン、ZFSを多用するワークフロー、その他のコンテナも実行する場合は、メモリを増やしましょう。追加のRAMはホストのキャッシュ性能を高め、サービス間のメモリ圧迫を軽減できますが、対応していないコーデック経路や限界に達したメディアエンジンを補うことはできません。
内蔵グラフィックスはシステムメモリを共有することがあり、Jellyfinは、デュアルチャネルのメモリ帯域幅が、ハードウェアトーンマッピングなど一部の負荷の高いiGPU処理に役立つと説明しています。したがって、容量とメモリチャネル構成は別々に判断する必要があります。「GBが多いこと」と「帯域幅が広いこと」は同じではありません。
IOPSとレイテンシは、映画のストリーミング性能ではなくJellyfinの状態データに使う
大容量メディアの読み出しはシーケンシャル処理なので、ファイルのビットレートを十分に上回る速度を出せるHDDであれば、問題なく配信できます。一方、データベースクエリ、アートワークの検索、検索インデックス、ユーザー状態の更新、キャッシュ処理は小さなランダムアクセスであり、レイテンシとIOPSがはるかに重要です。
Jellyfinのストレージガイドでは、ランダムアクセスのワークロードがあるためJellyfinのファイルにはSSDを明確に推奨する一方、ソースのビットレートを維持できるストレージにメディアを置くことは許容しています。これが、SSDのメタデータ層によって、エンコード済みの動画自体を変更せずにインターフェースの応答性を高められる理由です。
再生がスムーズなのにUIの動作が遅い場合は、メディアプールを交換するのではなく、アプリデータのレイテンシを測定しましょう。反対に、複数のユーザーが同じリモートストレージから読み出すときだけ高ビットレートのストリームが停止する場合は、IOPSベンチマークを追う前に、シーケンシャルスループットとネットワーク経路を調べてください。
上位モデルに費用をかける前に、仕様表を4つのテストに置き換える
4つの経路を実行または想定します。通常のダイレクトプレイ、最も厳しい条件のクライアントトランスコード、バックグラウンド処理中のライブラリ閲覧・検索、そして複数ユーザーがピーク時に利用する状態です。CPU使用率、ハードウェアアクセラレーションの状態、メモリ圧迫、アプリデータのレイテンシ、ネットワークとストレージのスループットを記録しましょう。
ZimaSpaceのハードウェアトランスコード検証ガイドは、設定スイッチを信じるだけでなく、デバイスが実際に使用されていることとFFmpegの動作を確認する必要がある理由を示しています。同じ原則はRAMとストレージにも当てはまります。実際に制約となっている経路を観察してください。
候補のマシンが4つのテストすべてを余裕を持って満たすなら、CPU、RAM、SSDの上位モデルを購入する前に、将来どの具体的な状況を解決したいのかを明確にしましょう。「より多い」こと自体は、購入の理由にはなりません。
測定したボトルネックを解消するアップグレードを選ぶ
変換が繰り返し制限要因になるならCPUまたはメディア性能を強化し、ホスト全体でメモリ圧迫が発生している、または同時実行するサービスにメモリが必要ならRAMを増設します。データベースやキャッシュのレイテンシが問題ならアプリデータ用SSDを強化し、継続的なソース読み出しが問題ならメディアストレージまたはネットワークを強化しましょう。
ZimaのJellyfinハードウェア要件ページは、クライアント互換性、ハードウェアアクセラレーション、メモリ、ストレージ、ネットワークを別々の選定軸として整理しているため、購入時の確認に利用できます。
ユーザー体験を左右するボトルネックが解消され、残りの仕様が判断に重要でなくなったら、そこで止めましょう。このJellyfinワークロードでは、それ以上ベンチマークスコアを上げても、得られる効果は次第に小さくなります。
おすすめ商品
購入ガイド
もっと読む
NAS購入前の家族写真移行リスクガイド
エクスポート後もオリジナルとメタデータが保持され、重複ファイルが分類され、ステージング領域に収まり、ロールバックによってソースがそのまま維持されるなら、写真用NASを購入する。
パスワード保管庫サーバーの可用性リスクガイド
キャッシュ済みアクセス、独立した復旧用認証情報、復元テスト、そして別の運用担当者を用意して、障害による締め出しを防げる場合にのみ、パスワード保管庫をセルフホストしてください。
初めて購入する人向けミニPC拡張リスクガイド
交換可能な部品、共有帯域幅、そして拡張パス全体が安定して手頃な価格で維持できるかを確認してから、ミニPCを購入しましょう。
