Plexのパフォーマンスの上限を実際に決めるものとは？

エヴァ・ウォン

IceWhale author

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

What Actually Sets the Plex Performance Ceiling? - Zima Store Online

Plexの性能上限は、サーバー内で最も高性能な仕様ではなく、再生経路で最初に飽和する依存要素によって決まります。

強力なCPUでもアップロード帯域幅の不足は解消できず、高速なネットワークでも、クライアントがコーデックに対応していなければトランスコードを防ぐことはできません。同様に、SSDはメタデータへの応答性を高めることはあっても、GPUが維持できるハードウェアトランスコードの数を増やすとは限りません。Plexを依存関係の連鎖として捉え、ハードウェア、ストレージ、ネットワーク、コンテナ設定を変更する前に、最初に失敗する段階を測定してください。

再生モードによって、最も重要なリソースが決まる

Direct Playでは、サーバーの主な処理がファイルの読み取りと送信になるため、CPU使用量を少なくできます。一方、トランスコードではCPUまたは専用ビデオハードウェアの負荷が高まり、一時ストレージも消費します。リモート再生では、LAN上にはないアップロード帯域幅の上限が加わる場合があります。

サーバーは、クライアントの互換性とストリーム要件に応じて、Direct Play、Direct Stream、トランスコードのいずれかを選択します。その結果、各セッションが消費するリソースが変わります。これがPlexの性能上限を確認する際の基準となります。

したがって、同じサーバーにも複数の性能上限があります。実用的な上限は常にワークロードによって異なり、Direct Playの上限、ソフトウェアトランスコードの上限、ハードウェアトランスコードの上限、またはリモート帯域幅の上限となります。

同時実行数が増えるのは、各セッションが使用するリソースだけ

同時に2つのセッションを実行しても、すべてのリソースが自動的に2倍になるわけではありません。メタデータキャッシュやネットワーク経路は共有される一方、トランスコードごとに計算処理と一時I/Oが追加されます。Direct Playのストリームでは、主にストレージの読み取りとネットワークトラフィックが増える場合があります。

Plexの性能上限を測定する際は、1つの平均指標だけに頼るのではなく、リソースごとのボトルネック確認で、CPU、メモリ、ネットワーク、ストレージ全体の使用率、飽和状態、エラーを確認してください。

この方法により、よくある誤りを防げます。総メモリ使用量が高く見えるためにRAMを増設したものの、実際の障害はトランスコーダーまたはアップロード回線が上限に達した瞬間に始まっていた、というケースです。

1つのベンチマークが誤解を招く場合

1080pの単一テストでは、4K HDRの字幕焼き付けを予測できません。また、LAN上のテストでは、低速なリモート接続の結果を予測できません。クライアントの機能やメディア形式によって経路が大きく変わるため、以前のボトルネックが解消され、別のボトルネックが主因になることがあります。

Plexの性能上限における障害発生の境界では、同一ホスト上に配置されたコンテナで測定可能なリソース干渉が発生する場合があります。そのため、共有ホスト上では、単独のベンチマークよりも同時実行テストの方が多くの情報を示します。

一度に変更する変数を1つだけにして、同じワークロードを繰り返してください。ボトルネックが別の段階へ移った場合は、結果を平均化してまとめるのではなく、新しい動作状態として扱います。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

最初に飽和する段階を見つける

まず再生モードを確認し、次に計算処理、ネットワーク、ストレージ、アプリデータの応答性、クライアントの互換性をこの順番で調べてください。1つの段階が再現性のある上限に達するまで、同時実行数を少しずつ増やします。テスト中にクライアント側の挙動とサーバー側の計算処理・ストレージの制限を切り分けるには、DASとNASの違いも役立ちます。

明示的なコンテナリソース制限を設定せずにPlexの性能上限が変わったと判断する前に、同じピーク時間帯に隣接するサービスがCPU、メモリ、ストレージI/Oを消費し、Plexの動作を変えていないか確認してください。

必要なワークロードを妨げている依存要素だけをアップグレードしてください。目標とするセッション数が余裕を持って処理できた時点で止めます。制限要因ではないコンポーネントの余分な容量を増やしても、観測される上限は上がりません。