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

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

実用的な設計では、Jellyfinの再生期限を守り、それを繰り返し妨げるサービスを制限するか、実行時刻をずらします。2つのサービスが理論上競合しうるというだけでサーバー全体を分割しないでください。実際に同時稼働させたときに飽和するリソースを分割または制限します。

制限を設定する前に、ピーク時の共有負荷を測定する

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

ZimaSpaceの既存の分析では、ピーク負荷の重なりと最初に競合するリソースを診断します。このセットアップガイドでは、その診断結果を受けて、特定した競合を分離する方針に落とし込みます。

再生の劣化と同じリソースの競合が繰り返し発生する場合に限り、そのリソースを制限してください。そうでなければ、実際の競合を解消できないまま性能が低下するおそれがあります。

JellyfinのCPUを枯渇させず、バッチ処理の上限を設定する

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

Dockerのリソース制御モデルを使えば、すべてのコンテナを無制限にするのではなく、CPUクォータ、CPUシェア、またはCPUセットを設定できます。ときどきリソースを融通できると便利な場合は、まずソフトな優先度設定を使い、バッチジョブが繰り返しすべてのコアを使い切る場合は、ハードな上限を設定してください。

ハードウェアトランスコードを有効にしているからといって、JellyfinのCPU上限を不自然に低く設定しないでください。ライブラリ処理、音声変換、プラグイン、未対応コーデックを使う処理では、引き続きCPUを使用します。

ホストのメモリ不足を引き起こすサービスを制限して、メモリを確保する

Jellyfin自体は少ないメモリでも問題なく動作することが多いですが、ホストはファイルシステムキャッシュやほかのサービスにもRAMを使います。写真インデクサー、VM、データベース、ローカルAIモデルが十分なメモリを消費すると、メモリ回収やスワップ、OOMによる強制終了が発生することがあります。

メモリ使用量が任意に増えるサービスや、バッチ処理を行うサービスにはハード上限を設定し、カーネルとファイルシステムキャッシュを健全に保てるだけの余裕をホストに残してください。隣接サービスによるシステム全体の不安定化を防ぐ場合、メモリ上限は有効です。一方、上限によってスワップが頻発し、ストレージ遅延が増えるなら逆効果です。

「使用済みRAM」だけを目安にせず、実際のワークロードでメモリ負荷とスワップの挙動を監視してください。

Featured

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

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

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

Jellyfinのハードウェアトランスコードは効率的ですが、同じGPUでAI推論、コンピュータービジョン、レンダリング、動画エンコードも実行されることがあります。GPUの総演算能力が十分でも、ビデオエンジン、メモリ、コピーエンジン、熱設計電力には限りがあります。

Jellyfinのハードウェアアクセラレーションの仕組みでは、固定機能のメディアエンジンが動画変換をCPUからオフロードすることが示されています。これにより効率は向上しますが、他のGPU利用サービスとの干渉が完全になくなるわけではありません。

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

バックアップやインデックス作成の集中によるストレージキューへの負荷を抑える

バックアップ、torrentの移動、写真のスキャン、またはVMが同じデバイス上で無関係なランダムI/Oを発生させるまでは、メディアの読み取りはシーケンシャルで問題が起きにくいことがあります。特にHDDでは、複数の独立したワークロード間でヘッドの移動を強いられると、影響が出やすくなります。

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

合格条件はユーザーから見て判断できるものです。負荷の高いサービスが予定された上限で稼働していても、再生が想定した遅延とバッファリングの目標範囲内に収まることです。

スケジュール設定から上限設定、物理的な分離へと段階的に進める

必要な重複稼働を、最小限の妥当な分離策を講じても再生障害が解消しない場合にのみ、Jellyfinを専用マシンへ移してください。2台目のホストは、測定で確認された障害の境界を解決するためのものであり、原因不明の設定問題を補うためのものではありません。