CPU、RAM、IOPSを最大スペックの順位ではなく、ワークロードのしきい値に置き換えて、Plex用ハードウェアを選びましょう。まず、サーバーが維持すべき再生経路と関連サービスを確認し、必要十分な最低基準を選びます。測定した制約がトリガーを超えた場合にのみ、アップグレードしてください。
仕様を読む前にPlexのワークロードを定義する
現実的に最も負荷が高くなる1時間を記録します。ダイレクト再生、リマックス、動画トランスコード、字幕の使用状況、リモート再生時のビットレート制限、ライブラリスキャン、競合するアプリケーションを含めてください。必要条件と任意の余裕を分けて考えます。仕様が重要なのは、これらの処理のいずれかを左右する場合、または複数の処理が重なる際の復旧余力を維持する場合だけです。
ワークロードサイジングのフレームワークでは、CPU、メモリ、ストレージ、ネットワークをそれぞれ異なる指標からサイジングすべき理由を説明しています。Plexでも同じ方法を使い、判断を単一の総合性能スコアにまとめないようにしましょう。
購入判定: 主要なプロセッサやメモリ容量が高くても、OS、ドライバーパス、ネットワークインターフェースが必要な再生経路に対応できない候補は除外します。
CPUをソフトウェアおよびハードウェアトランスコード能力に置き換える
ダイレクト再生を優先するサーバーでは、通常CPU負荷は控えめで、コア数を増やしても再生が改善しない場合があります。ソフトウェア動画トランスコードでは必要な基準が変わります。一方、対応するハードウェアトランスコードを利用すれば、動画処理の大部分をメディアエンジンに移せます。それでもCPUは、音声、字幕、ライブラリ処理、アクセラレーションからフォールバックした処理を担当します。
実用的なハードウェアトランスコードガイドは、コア数だけではPlexの処理能力を予測できない理由を示しています。候補にハードウェアトランコードの余力があると判断する前に、ソースコーデック、ビット深度、出力形式、トーンマッピング、字幕、アクセラレーターの世代を確認してください。
最低基準: 必要なセッションの中で最も負荷の高いものが、動画以外の処理に余裕を残した状態でリアルタイム変換速度を上回る必要があります。再現テストで現在の経路が飽和した場合、または必要なコーデックに対応していない場合にのみ、CPUやメディアエンジンの世代をアップグレードします。
RAMを利用可能な余力に置き換える
RAMには、OS、Plex、ファイルシステムキャッシュ、データベース、関連サービスを、継続的なスワップやメモリ不足による終了なしに収める必要があります。Linuxは余ったメモリを意図的にキャッシュとして利用するため、空きメモリが少ないこと自体は障害ではありません。購入時に有用な指標は、ビジー時間帯の利用可能メモリとメモリプレッシャーです。
Linuxのメモリ使用量の仕組みを理解すれば、キャッシュデータによって空きメモリの欄が小さく見えるという理由でRAMを過剰に購入するのを防げます。測定したワーキングセットに復旧余力を加えて容量を決めましょう。
アップグレードのトリガー: 想定する構成でスワップが継続的に発生する、プレッシャーストールが起きる、コンテナが再起動する、または意図的に容量を制限したメモリバックドワークスペースを確保できない場合は、より多くのRAMを選びます。CPUやメディアエンジンが制限要因となっているコーデック処理は、RAMを増やしても高速化しません。
IOPSとスループットを別々のストレージ層に置き換える
メディアファイルは通常、大きなシーケンシャル読み取りを発生させるため、総合スループットとネットワーク速度が重要です。Plexのメタデータ、サムネイル、インデックス、データベースは小さなI/Oを発生させるため、レイテンシーとIOPSが応答性に影響します。大容量のメディアディスクは十分にストリーミングできても、アプリケーションの状態が混雑したキューを共有していると、ライブラリの閲覧が遅くなる場合があります。
IOPSとレイテンシーの解説では、1つの広告上の速度だけでは両方のパターンを表せない理由を説明しています。Plexのアプリケーション状態には、信頼性の高い低レイテンシーのストレージを優先し、大容量のメディアストレージは容量、持続的な読み取り性能、将来の増加量を基準に選びます。
アップグレードのトリガー: メディアのスループットが健全なまま、スキャン中に小さなI/Oのレイテンシーが上昇する場合は、より高速なメタデータ層を導入します。同時再生ストリームが実際にディスクやネットワークの持続限界に近づいた場合にのみ、メディア経路の帯域幅を増やします。
トランスコード用ストレージがRAMの容量階層を変えるか判断する
ディスクベースのトランスコードディレクトリには、容量、書き込み性能、適切な権限、クリーンアップの動作が必要です。メモリベースのディレクトリはディスクへの書き込みを避けられますが、システムRAMを予約または消費します。この方法を選ぶことで、より大容量のメモリ階層が必要になる場合はありますが、Plexに必須の機能と考えるべきではありません。
RAMトランスコードのトレードオフに関する実践テストでは、同時セッション数の実測値からワークスペースの容量を決めるべき理由を示しています。シーク、高ビットレート、複数クライアントによって、一時的な使用量は変化します。
除外条件: 上限のないRAMトランスコード経路が安全に動作し続けると想定して、メモリ容量の小さいサーバーを選ばないでください。システム用に十分な利用可能メモリを確保するか、ディスクベースのワークスペースを使用し、測定結果に応じて必要な容量を購入します。
測定チェックリストで購入を最終決定する
各候補について、ダイレクト再生1本、一般的なトランスコード1本、想定される最も負荷の高いトランスコード1本、ライブラリスキャン、最も負荷の高い関連サービスを使ってテストします。コアごとのCPU使用率、ハードウェアデコードとエンコードの稼働状況、最小利用可能メモリ、スワップまたはOOMイベント、ストレージレイテンシー、スループット、クライアント側の再生状態を記録してください。
コンテナリソースの測定方法は、コンテナ化した環境で再現性のある観測手順を提供します。Plexを直接インストールする場合は、同等のホストメトリクスを使用してください。
必要なすべてのテストに明確な余力を残して合格する、最も安価な候補を選びます。測定結果を変えない限り、使用しない最大RAM容量、ライブラリ全体のテラバイト数、合成テストでのピークIOPS、余分なCPUコアは評価を下げて考えます。Plex向けNAS仕様ガイドは、測定結果を最終的なサーバー候補リストに反映するのに役立ちます。
| 仕様 | 必要十分であることを示す証拠 | アップグレードのトリガー |
|---|---|---|
| CPUまたはメディアエンジン | 最も負荷の高い必要経路がリアルタイムを上回る | 非対応コーデックまたは変換経路の飽和 |
| RAM | ワーキングセットが復旧余力を含めて収まる | スワップ、プレッシャー、OOM、または容量を制限したRAMワークスペース |
| IOPSとレイテンシー | スキャン中もメタデータが応答性を維持する | 小さなI/Oのレイテンシーによってライブラリ処理が遅延する |
| スループット | 同時ストリームが持続容量を下回る | メディアまたはネットワークの測定上の飽和 |
購入ガイド
もっと読む

重み付け基準を使ってPlex向けホームサーバーを絞り込む方法
購入前に不確実性を明らかにし、必須条件と希望条件を分けた、再現可能なPlex購入マトリックス。

Plexサーバーはどのようなサポートとアップグレードライフサイクルを提供すべきか?
Plexサーバーのサポート、アップデート履歴、互換性、修理のしやすさ、コスト、移行準備状況を合否判定する購入フレームワーク。

成長するPlex環境にはどれくらいのストレージ容量が必要?
増え続けるPlexライブラリには、実際に測定したメディア構成、維持する成長分、保護用のオーバーヘッド、空き容量の余裕、そして計画的な拡張方針に基づく容量が必要です。

