より多くのCPUコアが実際に役立つJellyfinのワークロードとは？
ワークロードに持続的なCPU並列処理、特にソフトウェアによる動画処理、同時実行されるCPUジョブ、大規模なスキャン、負荷の高い併設サービスが含まれる場合、CPUコア数が多いほどJellyfinに有利です。ただし、通常のダイレクトプレイや多くのハードウェアアクセラレーションストリームでは、効果は限定的です。
まずは必要十分な最低基準から：ダイレクトプレイに大容量CPUは不要
ダイレクトプレイでは、主に既存のメディアファイルをストレージからネットワーク経由でクライアントへ送ります。サーバーは認証、データベースクエリ、メタデータ、通常のアプリケーション処理を引き続き行いますが、動画の全フレームをデコードして再エンコードするわけではありません。ダイレクトプレイを中心に利用する家庭では、多コアのデスクトップ向けCPUよりも、十分な応答性を備えた最新の省電力CPUのほうが合理的な場合があります。
最新のダイレクトプレイとトランスコードの解説では、メディア処理経路が変わるとCPU負荷が大きく変化する理由が説明されています。そのため、コア数を確認する前に、まずクライアントの互換性を確認することが重要です。
ライブラリの容量がテラバイト単位で増えたから、あるいは登録ユーザーが増えたからといって、コア数を増やす必要はありません。同時に実行されるアクティブな処理がCPUを消費する場合にアップグレードしましょう。夜間の最大負荷がダイレクトプレイ3本と低負荷のデータベース処理にとどまるなら、使われない汎用コアよりも、信頼性の高いストレージ、ネットワーク、対応メディアエンジンに優先して予算を配分するべきです。
ソフトウェア動画トランスコードは、コア数を増やす最も明確なきっかけ
動画をソフトウェアでデコード、フィルタリング、エンコードする必要がある場合、Jellyfinは複数スレッドを利用できるFFmpeg処理を実行します。コア数を増やすことで処理性能が向上したり、複数のソフトウェアトランスコードを同時に処理できたりしますが、拡張性はコーデック、解像度、フィルター、スレッドモデル、メモリ帯域幅によって異なります。「ストリーム1本につき1コア」という単純な計算式ではありません。
実用的なFFmpegスケーリングガイドでは、スレッド数が増えるにつれて速度向上が頭打ちになり、スケジューリングのオーバーヘッドが増える理由が説明されています。購入時の意味は明確です。コア数は重要ですが、やがて追加したコア数に比例した効果は得られなくなります。
代表的なソフトウェアトランスコードがリアルタイム速度を維持できない場合や、複数のCPUのみの変換処理が重なる場合は、コア数を増やしましょう。特定のコーデックや字幕処理で、たまにしかソフトウェア処理が必要にならないなら、大型CPUよりも、より適切なクライアントやハードウェアアクセラレーション経路を導入したほうが、低コストで問題を解消できる場合があります。
大規模なライブラリスキャンや同時実行されるバックグラウンドジョブには、追加のCPU余力が役立つ
ライブラリのインポート、メタデータ処理、画像処理、チャプターやトリックプレイの生成、プラグインタスクは、通常の閲覧よりも並列性の高い負荷の急増を引き起こすことがあります。サーバーに家庭内の再生へ応答し続けることも求める場合、コア数に余裕があれば、こうしたメンテナンス時間を短縮できます。
ライブラリのメンテナンス中は、Jellyfinのバックグラウンド処理自体がアクティブなCPU負荷になることがあります。最新のスケジュールタスク最適化ガイドでは、ライブラリスキャン、メタデータ更新、画像抽出、トリックプレイ、関連ジョブがCPUスパイクの原因となり、再生時間帯を避けて再スケジュールする必要がある場合について説明しています。
スキャンや分析にかかる時間が実際の運用上の問題であり、データベースとストレージが処理に追いつける場合は、コア数を増やす価値があります。一方、スキャンが遅いHDD、ネットワークマウント、メタデータプロバイダー、データベースロックを待っているだけなら、コア数を増やしても効果はありません。購入前に、CPU使用率とタスク所要時間を合わせて測定してください。
ハードウェアアクセラレーションにより、動画処理でのCPUコア数の価値は下がる
最新の内蔵またはディスクリートのメディアエンジンを使えば、通常ならCPU使用率の大部分を占めるデコードとエンコードの処理をオフロードできます。この構成でもCPUはアプリケーションロジック、音声、対応していないコーデック、字幕やソフトウェア処理にフォールバックするフィルター、その他のサービスを処理します。しかし、多コアCPUが動画トランスコードの主なリソースではなくなります。
最新のJellyfinハードウェアトランスコードガイドでは、Intel QSV、NVIDIA NVENC、AMD VA-APIを分けて解説し、有効な動画処理経路には、対応するメディアデバイスが公開され、正常に動作確認されていることが重要だと示しています。動画変換が主な負荷である場合、これはCPUのコア数よりも重要な購入判断基準です。
家庭内の厳しい利用ケースが対応動画のトランスコードであるなら、検証済みのメディアエンジンを備えた控えめなCPUを優先しましょう。ハードウェアアクセラレーションが機能した後も、対応していないソフトウェアデコード、字幕の焼き込み、音声処理、プラグイン、Jellyfin以外のサービスによってCPUが測定上のボトルネックになるなら、より高性能なCPUを選びます。
併設サービスが、Jellyfin単体では使わないコア数を正当化することがある
Jellyfinのホストでは、ダウンロードの自動化、ファイルインデックス作成、Home Assistant、写真管理、バックアップ、VM、ローカルAIなども実行することがよくあります。最新のホームラボ向けミニPC比較では、共有ホストに適したCPUクラスを、RAM、電力、ネットワーク、混在サービスへの適性と併せて評価しています。この場合、購入するコアはJellyfinの1本のストリームのためではなく、ホスト上で重なるワークロードのためのものです。
ZimaSpaceのCPU、RAM、IOPSガイドも同じく、ワークロードを起点に判断しています。アクティブな処理経路がCPUバウンドの場合にのみ、CPUへ追加予算を割く価値があります。
合計ピーク負荷に合わせて選定し、そのうえで家庭内の遅延に敏感な再生処理のための余力を確保しましょう。バックアップを午前3時にスケジュールできるなら、映画鑑賞時間と重なることを想定してコアを購入する必要はありません。2つのサービスが同時にピークへ達する必要があるなら、その同時実行数を正直に見積もってください。
スペック表ではなく、コア数アップグレードの判断基準を使う
| 確認されたJellyfinのワークロード | コア数を増やすべきか | まず行うべきこと |
|---|---|---|
| ほとんどがダイレクトプレイ | 通常は不要 | クライアント、ネットワーク、ストレージを確認する |
| 対応済みのハードウェアトランスコード | 効果は限定的 | メディアエンジンとドライバーを確認する |
| ソフトウェア動画トランスコードを繰り返し実行 | 多くの場合は必要 | 実際のファイルとスレッドスケーリングをベンチマークする |
| アクティブユーザーがいる状態での大規模スキャン | 場合による | CPU負荷とデータベース／ストレージ待ちを確認する |
| JellyfinとCPU負荷の高いコンテナ／VM | 多くの場合は必要 | 合計ピーク負荷と余力に合わせて選定する |
現在のサーバーで、代表的なピーク負荷を1つベンチマークしてください。制御されたスレッドスケーリングテストは有用なモデルです。スレッドを追加しても結果が変わらなくなるまでしか処理性能は向上しないことが分かるためです。トランスコード速度がリアルタイムを下回る、スキャンの遅延が許容できなくなる、その他のサービスが再生用の余力を消費する、といった状態になるまでJellyfinの負荷を高め、そのうえで問題が発生した指標を基準に候補CPUを比較しましょう。
ハードウェアアクセラレーションが検証済みで、CPUに安定した余力があるなら、コア数の少ない選択肢を購入しましょう。同じ制御されたテストでCPUが飽和し、ワークロードが複数コアにわたってスケールする場合は、上位モデルへ移行します。ストレージ、メディアエンジンの互換性、ネットワーク、温度のいずれかが先に問題になるなら、より多いコア数は無視してください。
おすすめ商品
購入ガイド
もっと読む
スペックを追いかけずに、3台以上のJellyfinサーバー候補を比較する方法
まずワークロード要件を満たさないJellyfinの候補を除外し、その後、残った候補について判断を左右する仕様、所有コスト、復旧性だけを比較します。
Jellyfinの保証・交換・復旧コストを評価する方法
より安価なJellyfinサーバーとは、必ずしも購入時の価格が最も低いものや保証期間が最も長いものではなく、回収可能な所有コストがより低いものです。
ユーザー数とデータ量の増加に伴い、JellyfinにはどれくらいのRAMが必要ですか？
アクティブユーザー数と同時に稼働するワークロードを基準にJellyfinのRAM容量を決め、ライブラリのサイズではなく、メモリプレッシャーやスワップ、OOMイベントが限界を示したときにアップグレードします。
