ユーザー数とデータ量の増加に伴い、JellyfinにはどれくらいのRAMが必要ですか？
Jellyfinに必要なRAM容量は、メディアライブラリのテラバイト数に正比例するのではなく、アクティブなワーキングセットとホスト上の他の処理に応じて増加します。専用のLinux Jellyfinサーバーなら、控えめなメモリ容量で十分な場合があります。ユーザー数が重要になるのは主に、同時セッション数、トランスコードバッファ、キャッシュの使用、または同時に稼働する関連サービスが増える場合です。
まず、OS、Jellyfin、そして実際に常時稼働させるサービスに十分なメモリを確保し、通常時の最も忙しい時間帯で状態を確認してください。アクティブなワーキングセットによって継続的な負荷、問題のあるメモリ回収やスワップ、OOMイベントが発生したらRAMを増設します。8GB、16GB、32GBのいずれかを、Jellyfinに当てはまる普遍的な基準にしないでください。
ライブラリ容量はRAM予算ではない
40TBのライブラリでも、ディスクからDirect Playすれば少ないRAMで動作できます。一方、より小さなサーバーでも、Jellyfin、ダウンロード自動化、写真のインデックス作成、VM、メモリ上のトランスコードを実行していれば、はるかに多くのRAMが必要になることがあります。ストレージ容量をメモリ容量の見積もりに変換する前に、アクティブなサービスとピーク時の重複を数えてください。
現在のJellyfinのメモリ容量の例では、周辺のワークロードが重くなるにつれてメモリが主に増加しています。ここから得られる有用な教訓は、公開されている容量区分を例として扱い、ライブラリ容量に応じてRAMを単純に増やすのではなく、ホスト全体を検証することです。
常時稼働するコンテナとVM、通常時に最も負荷の高いスキャンやトランスコード処理、家庭内での同時セッション数の最大値を一覧にしてください。RAM予算は、そのワークロードに耐えられる必要があります。
ユーザー数が重要になるのはワークロードが重なる場合だけ
アカウントを1つ追加するだけなら、消費するリソースはわずかです。同時再生、異なるクライアント経路、字幕処理、ダウンロード、同時実行されるバックグラウンドタスクが加わると、アクティブなワーキングセットが変化します。重要なのは登録ユーザー数ではなく、最も忙しい数人のユーザーが同時に発生させる処理です。
メディアスタックは、サーバー本体以外にもすぐに拡大します。この家庭用NASのメディアアプリスタックが示すように、Jellyfinは通常、リクエスト、インデクサー、字幕、ダウンロードの各サービスと並行して動作し、それぞれが独自にメモリを消費します。
通常使用する関連コンテナを稼働させたまま、ピーク時の再生をテストしてください。Jellyfin単体では安定しているのに、スタックが重なるときだけホストがスワップしたりプロセスを終了させたりするなら、ユーザー数を問題視するのではなく、共有ホスト全体に合わせて容量を決めます。
Linuxのキャッシュにより「使用中RAM」は購入判断の悪い基準になる
Linuxは、アイドル状態のメモリをファイルシステムキャッシュとして意図的に使用します。そのため、使用済みメモリが多く表示されても、回収可能な容量が十分に残っている場合があります。空きメモリの表示が少ないという理由だけでRAMを購入すると、無駄な出費になる可能性があります。
アプリケーションがメモリを必要とすると、Linuxのファイルシステムキャッシュは回収可能です。アイドル状態のサーバーでRAMの大半が視覚的に「空き」に戻ることを期待するのではなく、使用可能メモリ、スワップ、メモリプレッシャー、OOMの挙動を確認してください。
システムが十分に稼働した後と、通常時で最も忙しい時間帯の両方で測定してください。キャッシュを多く使用していても健全なホストと、Jellyfinの応答性を維持するために常にメモリを回収したり、アクティブなページをスワップへ移動したりするマシンは別物です。
コンテナには、回収できないワーキングセットを超える余裕が必要
JellyfinをcgroupまたはDockerのメモリ制限下で実行する場合、使用量には複数のメモリ種別が含まれます。匿名アプリケーションメモリ、ファイルキャッシュ、共有メモリ、カーネルによる使用量は回収のされ方が同じではないため、1つの割合だけでは制限が実際に危険かどうかを判断できません。
コンテナのメモリ内訳では、匿名メモリと回収可能なファイルキャッシュを分けて確認できます。また、1つの合計使用量だけでなく、cgroupのプレッシャーやOOMシグナルを確認することが推奨されています。
ライブラリのスキャン、プラグインのタスク、2本目のストリームに必要な一時的な余裕がなくなるほど、安定時のベースラインぎりぎりに制限を設定しないでください。逆に、使用可能なホストメモリが健全に保たれているなら、キャッシュを多く使用した1回の測定結果だけを理由に制限を倍にしないでください。
一時的なRAMストレージは予算を急速に変化させる
tmpfsのトランスコードディレクトリやその他のメモリ上のスクラッチ領域は、実際のシステムRAMを消費します。そのため、余裕のあるサーバーがメモリプレッシャーの問題に陥る可能性があります。ピーク使用量は、ファイルサイズ、同時変換数、シーク、クリーンアップの挙動によって変化します。
RAM上でトランスコードする場合は、観測されたワーキングセットの最大値を測定し、その容量をJellyfinプロセスのメモリとは別に計上してください。予測可能なメモリ余裕を重視する場合は、一時的な書き込みを避けることよりも、ディスク上のSSDスクラッチ領域を使用するほうがよい選択になる可能性があります。
メモリプレッシャーが繰り返し発生する場合だけアップグレードする
| 観測された兆候 | 解釈 | RAMへの対応 |
|---|---|---|
| 空きRAMが少ないが、使用可能RAMは多く、スワップの負荷もない | 健全なキャッシュ使用 | この兆候だけではアップグレードしない |
| 通常のピーク時に使用可能RAMが急減する | ワーキングセットが容量に近い | 余裕を増やすか、同時実行するサービスを減らす |
| スワップやメモリ回収による停止が繰り返される | メモリプレッシャーがレイテンシに影響している | RAMを増やすか、アクティブなワーキングセットを減らす |
| コンテナのOOM / exit 137 | 制限またはホストのメモリが不足している | 診断後に制限、メモリリーク、または容量の問題を修正する |
| 新しいVMや重いサービスを導入する予定がある | Jellyfin以外の処理が増加する | 合算したピーク負荷に合わせてホスト容量を決める |
ホストをコンテナ化している場合は、DIMMの容量を変更する前に、プレッシャーとcgroupのイベントを確認してください。cgroup v2のワークフローでは、memory.high、memory.max、PSI、OOMカウンターを確認できます。これにより、大きくても健全なキャッシュフットプリントと、継続的なプレッシャーを区別しやすくなります。
ZimaSpaceによる同時ワークロード別のJellyfin容量分析も同じ原則に基づいています。ユーザー数が重要になるのは、それをアクティブなリソース需要と、最初に余裕がなくなるリソースへ変換した後だけです。
測定した多忙な時間帯を健全に保ち、現実的なアップグレード経路も残せる、最小のRAM容量を選んでください。より多くのメモリは、実際のプレッシャーを防いだり、計画している同居ワークロードを支えたりする場合に有効です。しかし、互換性のないクライアントをDirect Playにしたり、弱いトランスコードエンジンを改善したりするものではありません。
おすすめ商品
購入ガイド
もっと読む
スペックを追いかけずに、3台以上のJellyfinサーバー候補を比較する方法
まずワークロード要件を満たさないJellyfinの候補を除外し、その後、残った候補について判断を左右する仕様、所有コスト、復旧性だけを比較します。
Jellyfinの保証・交換・復旧コストを評価する方法
より安価なJellyfinサーバーとは、必ずしも購入時の価格が最も低いものや保証期間が最も長いものではなく、回収可能な所有コストがより低いものです。
より多くのCPUコアが実際に役立つJellyfinのワークロードとは？
実測したJellyfinの処理がCPU並列化されている場合にのみ、CPUコア数を増やしましょう。Direct Playやハードウェアアクセラレーションによる動画再生では、通常、ボトルネックは別の箇所に移ります。
