異なるクライアントが同時接続すると、Plexがより多くのGPUメモリを使用するのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Plex Use More GPU Memory Under Mixed-Client Concurrency? - Zima Store Online

Plexは、同時セッションで異なるデコード、変換、エンコード用のワーキングセットを常駐させる必要がある場合、異なるクライアントが混在する同時利用時に、より多くのGPUメモリを使用します。

重要な変数は、単純な視聴者数ではありません。1080p H.264の変換、4K HEVC HDRの変換、Direct Playセッションは、同時にまったく異なるGPUパスを使用する可能性があります。VRAMをボトルネックと見なす前に、ビデオメモリの負荷を、エンコーダーのスループット、CPUフォールバック、ストレージやネットワークの制限から切り分けることが有効です。

異なるクライアントは異なるGPUワーキングセットを作る

クライアント構成が混在すると、Plexがアクティブな各セッション用に準備しておく必要があるものも変わります。あるテレビは元のHEVC映像を受け入れられても、別のブラウザではH.264出力が必要になり、通信状態が制限されたリモート接続のスマートフォンでは、より低い解像度を要求する場合があります。そのため、各セッションは同一のワークロードを複製したようにGPUリソースを消費するわけではありません。

ビデオ変換が必要な場合、Plexはコーデック固有のデコードおよびエンコードのサポートに加え、中間フレーム用のバッファも必要とします。ハードウェアによるビデオのデコードおよびエンコードパスは、ソースと出力の組み合わせによって変わります。そのため、同じ公称解像度の2つのセッションでも、必要なメモリ容量が異なることがあります。

Direct Playは、サーバーによるビデオのデコードと再エンコードを必要としないため、比較用の基準として役立ちます。あるクライアントがDirect Playからハードウェアトランスコードに切り替わったときだけGPUメモリが増加するなら、その追加割り当ては同時実行そのものではなく、変換パスに属しています。

解像度とコーデックによってフレームサーフェスのサイズが変わる

ビデオメモリは、ストレージから届く圧縮ファイル以外にも使用されます。ハードウェアデコーダーとエンコーダーは、デコード済みのピクチャサーフェス、参照フレーム、中間出力バッファを扱います。これらのサイズは、解像度、ビット深度、クロマ形式、コーデックの動作によって変わります。そのため、同時実行数を考慮する前から、4Kフレームは1080pフレームより大きなワーキングセットを必要とします。

4K HEVCは、1080pのAVCより多くのVRAMを必要とする場合があります。ただし、これはワークロードを判断する手がかりとして扱い、ストリームごとの固定的な計算式とは考えないでください。ドライバーのバージョン、トーンマッピングのパス、GPUアーキテクチャ、Plexのリリースによって、実際の割り当ては変わる可能性があります。

診断上の結論はシンプルです。ソースの種類だけを変えながら、同じ数のセッションを比較してください。2つの1080p変換には十分な余裕があるのに、そのうち1つを4K HEVCに置き換えるとメモリ使用量が大幅に増えるなら、解像度とコーデック用のサーフェスが原因の一部です。

トーンマッピングと変換ステージが別のメモリ層を追加する

変換には、ある形式をデコードして別の形式にエンコードする以上の処理が含まれることがあります。スケーリング、色変換、HDRからSDRへのトーンマッピング、字幕の合成によって、デコーダーやエンコーダーのバッファと同時に存在する中間サーフェスが追加される場合があります。これらのステージは、同じライブラリから異なる出力を複数のクライアントが必要とするときに、特に重要になります。

コンテナ内では、ハードウェアビデオ処理に使用するレンダーデバイスノードが、GPUメモリの使用量を正しく判断する前にPlexからアクセスできる状態になっていなければなりません。アクセスできない場合、CPUフォールバックによってVRAM使用量が低く見える一方で、高負荷の処理が別の場所に移っている可能性があります。

VRAM使用量が低いのにCPU使用率が高い場合は、GPUが活用されていないと判断する前に、処理パスを確認してください。逆も同様です。GPUメモリ使用量が高くてもトランスコード速度が正常なら、容量不足ではなく、通常のメモリ常駐である可能性があります。

Featured

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

ZimaCube2

ワーキングセットが重なると同時実行が影響する

ハードウェアトランスコード中の各セッションは、再生が続く間、それぞれのアクティブなデコードおよびエンコード状態を保持します。クライアントが混在していると、これらの状態は異なる場合があり、同時に維持されるため、GPUメモリの総使用量は単純な視聴者数から予想するより速く増加することがあります。複数のユーザーが短時間のうちにシーク、再生開始、画質変更を行う場合、この重複はより重要になります。

ある測定済みのGTX 1660 Ti環境では、1つの4Kトランスコードで約600MBのGPUメモリが使用されました。これは測定可能なメモリ常駐量の一例であり、すべての4Kストリームに推奨されるVRAM容量ではありません。

同一のテストファイルをループ再生するのではなく、現実的に想定される最も負荷の高い組み合わせを使用してください。クライアントが混在する同時利用こそ、同一ストリームに基づく推定を不確かなものにする条件だからです。実際に家庭で使用するコーデック、HDRの状態、出力画質、クライアントをワークロードに含める必要があります。

メモリ負荷を他のGPU制限から切り分ける

VRAMが満杯でもエンコーダーにスループットの余力が残っていることがあり、逆にVRAMが十分に残っていても、コーデック処理、セッション数の上限、ドライバーパス、CPUのみの処理が遅延する場合があります。Quick Syncは適切なワークロードで複数のトランスコードを処理できますが、だからといってメモリ容量が同時実行数を決める唯一の制限になるわけではありません。

GPUメモリ、ビデオエンジンの使用率、トランスコード速度、CPU使用率、再生状態を同時に確認してください。割り当て量がデバイスの上限に近づくにつれて、新しいセッションやより負荷の高いセッションが失敗し、そのほかの処理パスが正常であるなら、メモリ負荷が原因である可能性が高くなります。そのパターンがなく使用率だけが高い場合は、別の原因を示しています。

サーバー全体の処理パスについては、コーデックのサポート、ストレージからのデータ供給、ハードウェアアクセラレーションの基準として、実績のある4K Plexサーバー環境を使用してください。GPUメモリはその構成要素の1つであり、ストリーム数を単独で決める仕様ではありません。