Plexは別のDockerコンテナとGPUを共有できますか？

エヴァ・ウォン

IceWhale author

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

Can Plex Share a GPU With Another Docker Container? - Zima Store Online

はい、Plexは別のDockerコンテナとGPUを共有できる場合があります。ただし、同じデバイスを両方のコンテナに公開しても、どちらのワークロードに対しても性能が確保されたり、保証されたりするわけではありません。

判断は、GPU、Linuxドライバー、コンテナランタイム、ワークロードの種類、そして各アプリケーションがビデオエンジン、コンピュート、メモリをどのように使用するかによって異なります。Intelの内蔵グラフィックスは、通常、/dev/dri などのLinuxデバイスノードを介して公開されます。一方、NVIDIAコンテナではNVIDIAコンテナランタイムまたはDockerのGPU予約機能を使用します。まずアクセスを設定し、その後Plexと2つ目のワークロードを同時に実行して、実際に想定している負荷の下でもPlexがハードウェアトランスコードを継続できるか確認してください。

まず単独でPlexがGPUを使用できることを確認する

共有をテストする前に、もう一方のGPUワークロードを停止し、Plexで強制的に1つのトランスコードを実行します。Plexがストリームに対してハードウェアアクセラレーションを報告し、ホスト側に想定どおりのビデオエンジンまたはGPUのアクティビティが表示されるはずです。Plexが単独でデバイスを使用できない場合、別のコンテナを追加すると原因の切り分けがさらに難しくなります。

Plexのハードウェアアクセラレーションストリーミングガイドでは、Docker環境でハードウェアアクセラレーションを利用するには、関連するカーネルデバイスをコンテナに公開する必要があると説明されています。ホストが検出したGPUはPlexから自動的に見えるとは限らないため、プラットフォームに適した現在のデバイス方式を使用してください。

トランスコード開始時間、CPU使用率、GPU／ビデオエンジンの使用率、再生の安定性を基準値として記録します。これにより、共有テストの比較対象が得られます。クリーンな基準値がなければ、後で発生した問題がリソース競合によるものか、元々のPlexのGPU設定によるものかを判断できません。

2つ目のコンテナにも同じデバイスを意図的に公開する

NVIDIAの場合、Docker Composeでは、サービスごとにGPUを台数またはデバイスIDで予約できます。2つのサービスが同じGPUを認識するよう設定すると、ランタイムはそのデバイスを両方に公開できます。ただし、これはアクセス制御であり、排他的な性能を保証する契約ではありません。IntelなどのLinuxデバイスでは、ドライバーが同時使用を許可している場合、両方のコンテナに同じ関連デバイスノードへのアクセス権を付与できます。

DockerのComposeのGPUサポートに関するドキュメントでは、サービスからGPUへのアクセスを要求し、特定のデバイスIDを指定する方法が説明されています。複数のGPUがある場合は、共有テスト中にPlexがデバイス間で意図せず切り替わらないよう、特定のデバイスを指定してください。

コンテナを再作成した後やアプリテンプレートを変更した後は、毎回権限を確認してください。2つ目のコンテナが動作しても、Plexが引き続きデバイスにアクセスできるとは限りません。また、Plexの設定でハードウェアアクセラレーションが有効と表示されていても、アクティブなストリームが実際にそれを使用しているとは限りません。

両方のワークロードを同時にテストし、最初に飽和するリソースを監視する

2つ目のワークロードを実際の利用状況に近いレベルで開始し、基準値の取得に使ったものと同じPlexトランスコードを強制的に実行します。再生の安定性、トランスコード速度、GPUメモリ、ビデオエンジン使用率、CPUへのフォールバックを比較してください。もう一方のワークロードがアクティブなときだけPlexがハードウェアモードからソフトウェアモードに切り替わったり、バッファリングを開始したりする場合、それは互換性の謎ではなく、競合が発生している結果です。

ZimaSpaceのGPU導入前チェックガイドでは、デバイスの検出だけでなく、コンテナからのアクセスや、ワークロードを組み合わせた状態でもストレージ、バックアップ、メディアタスクが応答性を維持できるかを確認するよう推奨しています。Plex以外のサービスも重要なNASでは、このシステム全体のテストが特に重要です。

ワークロードが異なるGPUエンジンを使用する場合、共有はうまく機能する可能性があります。一方、両方が同じビデオエンコード／デコードエンジン、メモリ、電力または熱的な余裕を奪い合う場合、性能が大幅に低下することがあります。全体の「GPU使用率」が低いからといって、Plexが必要とする特定のビデオエンジンが空いているとは限りません。

-15% OFF

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

Single board computer zimaboard2

共有が適さなくなる境界を設定する

Plexがハードウェアモードを維持し、2つ目のコンテナが目標を達成し、組み合わせた負荷の下でもNASの応答性が保たれるなら、共有構成を維持して問題ありません。通常のライフサイクルイベント後もデバイスマッピングと権限が維持されることを確認するため、Plexの再起動後と2つ目のコンテナの再起動後にもテストを繰り返してください。

競合が一時的なものであれば、2つ目の重いワークロードをストリーミングのピーク時間帯から外してスケジュールするか、アプリケーションレベルの制限を追加します。両方のワークロードを常に最大負荷で同時に実行する必要があり、一方がもう一方のリソースを継続的に奪う場合は、不安定な優先度調整を試すより、2つ目のアクセラレーターを専用に割り当てるか、一方のワークロードを別のホストへ移してください。

もう一方を停止している状態でもいずれかのコンテナがGPUを失う場合は、ドライバーまたはランタイムのトラブルシューティングに進んでください。共有の問題は、両方のアプリケーションがそれぞれ単独でデバイスにアクセスでき、同時使用時にのみ障害が発生することを確認してから診断すべきです。