リソースを大量に消費するサービスと共有しているサーバー上で Jellyfin を分離する方法

JellyfinとAI、写真のインデックス作成、VM、バックアップ、ダウンローダーなどの負荷の高いサービスで1台のサーバーを共有する場合、競合の境界を明確にすればうまく運用できます。コンテナはプロセスとファイルシステムを分離しますが、CPUサイクル、メモリ、ストレージキュー、GPUエンジンを自動的に予約するわけではありません。

実用的な設計は、まずJellyfinの再生期限を守り、その期限に繰り返し違反する側のサービスを制限または再スケジュールすることです。2つのサービスが理論上競合し得るからといって、サーバー全体を分割する必要はありません。実際の同時実行時に飽和するリソースだけを分離または制限してください。

制限を追加する前に共有時のピークを測定する

まずJellyfinで代表的な再生ケースを1つ実行し、その後、負荷の高いサービスを通常のピーク状態で追加します。初回フレームの表示時間、バッファリング、トランスコード速度、CPU、メモリプレッシャー、ストレージレイテンシ、GPUアクティビティを記録してください。

既存のZimaSpaceによるピーク時の重複と最初に競合するリソースの分析で診断を行えます。このセットアップガイドでは、その診断後に、特定された競合を分離ポリシーへと落とし込みます。

再生品質の低下と同じリソースの逼迫が繰り返し同時に発生する場合にのみ、そのリソースを制限してください。そうでなければ、実際の競合を解決しないままパフォーマンスだけを低下させる可能性があります。

CPU制限はJellyfinを圧迫するためではなく、バッチ処理を抑えるために使う

CPU負荷の高いインデックス作成、圧縮、ソフトウェアエンコード、ビルド処理は、利用可能なすべてのコアを占有することがあります。Jellyfinのダイレクト再生は問題なくても、音声変換、字幕の焼き付け、ソフトウェアフォールバックが発生すると、突然CPUの余裕が必要になる場合があります。

Dockerのリソース制御モデルでは、すべてのコンテナを無制限のままにせず、CPUクォータ、CPUシェア、cpusetを設定できます。一時的な借用が有効な場合は、まずソフトな優先度設定を使用してください。バッチジョブが繰り返しすべてのコアを占有する場合は、ハード上限を設定します。

ハードウェアトランスコードが有効だからといって、Jellyfinに極端に小さいCPU制限を設定しないでください。ライブラリ処理、音声変換、プラグイン、未対応コーデックの処理では、依然としてCPUが使用されます。

他のサービスがホストのメモリプレッシャーを引き起こさないようにメモリを確保する

Jellyfin自体は比較的少ないメモリで快適に動作することが多い一方、ホストはファイルシステムキャッシュや他のサービスにもRAMを使用します。写真インデクサー、VM、データベース、ローカルAIモデルによって、メモリ再利用、スワップ、OOMキルが発生するほどメモリを消費することがあります。

メモリの増加が任意またはバッチ処理に伴うサービスにはハードリミットを設定し、カーネルとファイルシステムキャッシュを健全に保てるだけの余裕をホストに残してください。メモリ上限は、他のサービスによるマシン全体の不安定化を防ぐ場合に有効です。一方、ストレージレイテンシを高める絶え間ないスワップを強制する場合は逆効果です。

「使用済みRAM」だけに頼らず、実際のワークロードでメモリプレッシャーとスワップの挙動を確認してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

GPUをキューのある共有アクセラレーターとして扱う

Jellyfinのハードウェアトランスコードは効率的ですが、同じGPUをAI推論、コンピュータービジョン、レンダリング、動画エンコードにも使用する場合があります。GPU全体の演算能力が十分でも、ビデオエンジン、メモリ、コピーエンジン、熱および電力の上限は有限です。

Jellyfinのハードウェアアクセラレーションの仕組みにより、専用メディアエンジンが動画変換をCPUからオフロードすることが確認できます。これにより効率は向上しますが、他のGPU利用者との干渉がゼロになるわけではありません。

ストリーミング中にAIを一時停止できるなら、スケジューリングだけで十分な場合があります。両方のワークロードを同時に低レイテンシで維持する必要がある場合は、アクセラレーターを分けるか、一方のサービスを別のホストへ移してください。

バックアップやインデックス作成のバーストからストレージキューを保護する

メディアの読み取りは、同じデバイス上でバックアップ、トレントの移動、写真スキャン、VMによる無関係なランダムI/Oが発生するまでは、シーケンシャルで処理しやすい場合があります。特に機械式ディスクでは、複数の独立したワークロード間でヘッドが頻繁に移動させられると影響を受けやすくなります。

可能であればJellyfinのアプリデータとトランスコードキャッシュを大量のメディアデータから分離し、大規模な書き込み処理は視聴のピーク時間外にスケジュールしてください。2つのサービスを同時に実行する必要がある場合は、ファイルシステムのスケジューラーが常に再生を優先すると期待せず、コンテナ、cgroup、VM、ストレージの各レイヤーでI/O制御を使用します。

合格条件はユーザーが体感できるものです。負荷の高いサービスを計画した上限で実行している間も、再生が想定したレイテンシとバッファリングの目標範囲内に収まることです。

スケジューリング、制限、物理分離の順に段階的に対応する

最小限の妥当な分離手順を実施しても、必要な同時実行によって再生が途切れる場合にのみ、Jellyfinを専用マシンへ移してください。2台目のホストは、未知の設定問題を補うためではなく、測定によって確認された障害の境界を解決するために導入すべきです。