Jellyfinにはどの程度のメモリ上限を設定すべきですか？

Jellyfinのメモリ上限を一律に設定しないでください。まず実測したワークロードを基準にし、ホストと周辺コンテナ用のメモリを確保したうえで、実際のピークを確認してからハード上限を設定します。

コンテナがホストのスワップ発生までメモリを増やし続けていますか。それとも、低すぎる上限によってOOMキルが繰り返されていますか。上限を変更する前に、アイドル時の使用量、ライブラリスキャン、メタデータ処理、同時トランスコード数、DockerまたはVMで利用可能なメモリを測定してください。元のワークロードが完了し、ホストに復旧の余裕が残っている場合にのみ、その上限は安全です。

通常のキャッシュ増加と常駐メモリの逼迫を分けて考える

まず、アイドル時と、繰り返し実行できる最も負荷の高いジョブの実行中に、コンテナのRSS、キャッシュ、スワップ、ホストの空きメモリを比較します。ファイルシステムキャッシュは大きく見えてもメモリリークとは限りません。一方、常駐メモリの増加とOOMイベントが同時に発生する場合は、実際の制約を示しています。

基本的なDocker版Jellyfinの構成は通常、数GB程度から始まり、トランスコードにはさらに多くのメモリが必要ですが、適切な値はワークロードによって異なります（ワークロードベースのメモリ基準）。

RSSが横ばいで、キャッシュだけが増加し、ホストに回収可能なメモリがある場合は、上限を厳しくせず監視してください。RSSがスワップやOOMキルのメッセージを伴って増加する場合は、トランスコードとライブラリのテストに進みます。

障害が発生するトリガーで上限をテストする

ライブラリスキャンを1回、代表的なトランスコードを1回、想定される同時ストリーム数を実行しながら、cgroupのメモリ使用量、メモリイベント、スワップ、ホストの負荷を記録します。実行ごとに変更するのはメモリ上限だけにしてください。

アイドル状態の再生には通るものの、字幕、HDR変換、インデックス作成で失敗する上限は、本番環境で有効な設定ではありません。どのトリガーが失敗を引き起こしたかを記録し、無関係なボトルネックのために上限を引き上げないようにします。

コンテナが停止させられた場合は、不要なトランスコードキャッシュを減らすか、負荷の高いジョブを分離してから、上限を引き上げてください。ホスト自体がスワップする場合は、同時実行数を減らすか、役割を別の場所へ移します。残りのRAMをすべてJellyfinに割り当てても、障害が別のサービスへ移るだけです。

停止境界を設定し、設定の永続性を確認する

ハード上限より低い位置にソフトアラートを設定し、ホスト、ストレージサービス、正常な再起動に十分なメモリを残します。ハード上限は、制限のないプロセスや容量不足のマシンを隠すためではなく、ホストを保護するためのものです。

上限を変更したら、コンテナを一度停止して再作成し、元のスキャンと再生のトリガーを繰り返します。再作成後も設定した上限が有効であることと、データベースに書き込み可能であることを確認してください。

ホストの余裕がない上限でもOOMイベントが続く場合、データベースが破損した場合、または再現可能なワークロードがないのにプロセスが増大する場合は、調整を中止して対応をエスカレーションします。大きな変更を行う前に、ログと最後に正常だった設定を保存してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

コールド再起動後にピーク時の再生を再確認する

ホストを再起動し、ストレージのマウントと周辺コンテナの起動を待ってから、元々上限の問題を明らかにしたものと同じマルチユーザーのストリーム構成を再現します。アイドル状態のダッシュボードや単一のDirect Playセッションだけで検証しないでください。

再生が安定し、スワップストームが発生せず、コンテナが上限を下回ったままで、新しいバックアップまたは再起動がメモリ関連のエラーなしに完了すれば、復旧が確認できます。結果を、調整前に記録した基準値と比較してください。

ピーク時のワークロードがホストの余裕を測定可能な状態で通過するなら、その設定を維持します。別のコンテナが起動した後だけ失敗する場合は、Jellyfinの上限を再度引き上げるのではなく、リソース予算を分割するか、競合するジョブのスケジュールを変更してください。