Plex向け8GB・16GB・32GB RAM比較:あなたのワークロードに合う容量はどれ?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

8GBはPlexを中心とした軽量なサーバーに適しており、16GBは中規模のアプリケーションスタックに適したバランスの良い容量です。32GBは仮想マシンや、意図的に確保したメモリベースのワークスペースに適しています。Plexにおいて、どの容量が自動的に高速になるわけではありません。実際の繁忙時間帯でも使用可能メモリと復旧用の余裕を確保できる、最小の容量を選ぶのが正解です。

まずメモリプレッシャーの判定基準を適用する

3つの容量を、同じOS、Plexのデプロイ方法、クライアント、同時セッション数、関連サービス、トランスコード先で比較します。使用可能メモリの最小値、スワップの発生状況、メモリプレッシャーによる停止、OOMイベントを記録してください。メディアファイルは通常ストレージ上に保持されるため、ライブラリのサイズだけをRAM容量の目安にすることはできません。

Linuxの使用可能メモリについての解説を読むと、空きメモリが少ないからといってメモリが枯渇しているとは限らない理由が分かります。ワーキングセットが収まり、再生に影響するプレッシャーがなければ、容量を増やしてもPlex上で目に見える効果がない場合があります。

軽量なPlex中心のホストでは8GBが有力

Plexが主なサービスで、クライアントの多くがダイレクト再生を行い、OSが軽量で、関連アプリケーションが少なく、一時的なトランスコードデータをディスク上に保持する場合は8GBを選びます。ただし、繁忙時間帯のテストでも復旧用の余裕が残る場合に限り、十分な容量を最も低い基準で確保できます。

メディアサーバーに8GBが適しているかを詳しく検討した記事でも、同じ条件付きの適合性が示されています。基本的な配信は可能ですが、トランスコードや追加サービスによって余裕は小さくなります。一般的なストリーム数の推定値を、異なるクライアント構成に対する保証として流用しないでください。

中規模の共有アプリケーションスタックでは16GBが有力

Plexとダウンロード自動化、監視、リバースプロキシ、データベース、または複数の中規模コンテナを同じホストで動かす場合は16GBを選びます。容量に余裕が増えることで、ファイルシステムキャッシュと突発的な負荷への余力を確保できますが、仮想マシン向けの容量まで支払う必要はありません。8GBでは運用上の調整が必要になる一方、32GBを使う明確な用途がない場合、16GBがバランスの良い選択です。

Dockerのメモリ動作についてのガイドでは、アイドル状態のコンテナの合計値だけでは不十分な理由が説明されています。混在するワークロードの実行中にワーキングセットとプレッシャーを比較し、Plexを圧迫する可能性のあるサービスには上限を設定してください。

仮想マシンや容量を制限したRAMワークスペースでは32GBが有力

ホスト上で仮想マシン、多数のアプリケーション、メモリを大量に消費するインデックス、または意図的にサイズを決めたRAMベースのトランスコードディレクトリを実行する場合は32GBを選びます。実験用の余裕も確保できますが、未使用の容量はPlexのパフォーマンス機能ではありません。CPU、アクセラレーター、ストレージ、ネットワークのいずれかが飽和している場合、16GBから32GBに増やしてもボトルネックは解消しません。

実用的なPlexのRAMトランスコード構成を見ると、このトレードオフが分かります。観測した同時セッション数をもとにワークスペースのサイズを決め、その割り当てとは別にOS用のメモリを確保してください。

コンテナとバックグラウンドジョブを同じ条件で測定する

ダイレクト再生、想定される中で最も負荷の高いトランスコード、ライブラリスキャン、最も重い定期ジョブを同時に実行します。3つの容量を、再生状態、使用可能メモリの最小値、スワップ、プロセスの再起動、リソース競合で比較してください。16GBのシステムが同じ測定上の余裕を維持できるなら、理論上の最大容量だけを理由に32GBを高く評価しないでください。

コンテナのリソース監視では、候補を同じ観点で観測できます。アイドル状態のスクリーンショット1枚より、代表的な負荷を1週間測定した結果のほうが有用です。

容量ごとの判定と、判定が変わる条件を使う

8GBが有力なのは、ピーク時のワーキングセットが収まる安定したPlex中心のホストです。16GBが有力なのは、必要な複数のサービスによって8GBでは余裕がなくなる一方、仮想マシンや大容量のメモリワークスペースがない場合です。32GBが有力なのは、明確な用途のある仮想マシン、アプリケーション、または容量を制限したtmpfsが16GBの余裕を消費する場合です。32GBを超える容量は、別途ワークステーションまたは仮想化向けの判断になります。

より広範なワークロード容量の決め方でも、最終的なルールが裏付けられています。現在の負荷に安全に対応できる最小容量を選び、測定結果が変わったら容量を調整してください。判定が変わるのは、定義したワークロードが使用可能メモリの境界を超えた場合だけです。

3つの容量のどれでも解決できない問題は、コーデックの非互換性、メディアエンジンの過負荷、メタデータストレージの遅さ、アップリンクの帯域不足です。RAMを購入する前に、これらのリソースを確認してください。Plex向けNAS仕様ガイドを使うと、実際に制限要因となっている仕様を特定できます。

容量 有力になる条件 不利になる条件
8GB Plex中心、軽量なOS、少数のサービス 混在するワークロードによってプレッシャーやスワップが発生する
16GB 中規模のコンテナスタックに余裕が必要 仮想マシンやRAMワークスペースが余裕を消費する
32GB 明確な用途のある仮想マシン、多数のアプリ、または容量を制限したtmpfs 容量が未使用のまま、または別のリソースが制限要因になる

製品比較

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.