PlexがCPU、RAM、ストレージ、ネットワークのどれによって制限されているかを見分ける方法
既知の1つのワークロードを再現し、ストリームが遅くなるのと同時に負荷が上昇するリソースを探すことで、Plexの制限要因を特定できます。最も忙しそうに見えるコンポーネントを最初にアップグレードしてはいけません。高い使用率が重要なのは、再生失敗と同時に発生している場合だけです。
まずは、1つのファイル、1つのクライアント、1つの再生モード、1つの時間帯に限定します。そのうえで、Plexの変換処理と、CPU、メモリ、ストレージ、ネットワークに関するOSのシグナルを切り分けます。疑わしいリソースを1つ変更したときに、他の条件を安定させたまま、元のPlexの症状が変化することを確認して初めてテスト完了です。
システムメトリクスを確認する前に、1つのPlexワークロードを再現する
問題を確実に再現できるファイルとクライアントを選びます。症状が、起動の遅さ、繰り返し発生するバッファリング、処理に遅れが生じるトランスコード、再生を遅くするスキャン、リモート接続時だけの失敗のいずれなのかを記録してください。症状ごとに、関係する待機経路が異なるためです。
Plex固有のトラブルシューティングは、一般的なCPUグラフではなく、アクティブなセッションの確認から始めるべきです。実用的なダッシュボード優先の確認では、サーバーの設定を変更する前に、ダイレクト再生、トランスコード、ネットワーク、ストレージの各分岐を切り分けられます。
システムメトリクスを収集する間は、ファイル、選択したトラック、クライアントの品質設定、同時実行中のワークロードを変えないでください。テストごとに症状が変わる場合は、同じ失敗を繰り返せるまでワークロードを単純化します。そうしないと、後で発生したCPUやディスクのスパイクが別のジョブによるものかもしれません。
Plexのセッションで配信と変換を切り分ける
問題が発生している間にPlexのセッションを確認します。ダイレクト再生では、サーバーは主に保存済みのメディアを配信します。一方、ビデオのトランスコードではリアルタイム変換の経路が追加されるため、ボトルネックがCPUやハードウェアのビデオエンジンに移る可能性があります。
この再生モードは、結論ではなく分岐として扱ってください。処理に遅れが生じるトランスコードでは、計算リソースが有力な候補になりますが、ダイレクト再生でバッファリングが発生する場合は、ストレージとネットワークも依然として対象です。字幕、音声、品質設定を変更すると同じファイルの再生モードが切り替わる場合は、ホストのメトリクスを比較する前に、元のリクエストでもう一度問題を再現してください。
このセクションを終える時点で、症状と結び付いた固定の再生モードが決まっている必要があります。失敗するテストがダイレクト再生なのかトランスコードなのかを明確に言えない場合は、ここで止めてください。メディア経路が安定する前にRAM、ディスク、ネットワークのデータを比較すると、残りのメトリクスを解釈しにくくなります。
CPUとRAMの負荷を同時にテストする
固定したPlexテスト中に、CPU使用率、ランキューまたはロード、利用可能メモリ、スワップの動作を監視します。CPU負荷が原因である可能性が高いのは、Plexプロセスまたはトランスコーダーが継続的に計算リソースを消費し、出力が遅れている場合です。メモリ負荷は、CPUだけが唯一の高負荷リソースではないにもかかわらず、システムがメモリの回収やスワップを開始して応答時間が悪化している場合に、より強く疑われます。
一般的なLinuxのパフォーマンス分析では、top、vmstat、iostat、sarなどのツールを使ってリソースの負荷を切り分けます。特に、CPU、メモリ、ディスク、ネットワークでは、全体の使用率を1つ見るのではなく、それぞれ異なる飽和シグナルを確認する必要があります。
失敗するトランスコードの間だけCPUが上限近くに張り付き、変換を取り除くか高速化するとストリームが回復するなら、計算リソースを主要なボトルネックと判断します。スワップやメモリ回収が増えている場合は、メモリを大量に消費する同時実行ジョブを減らすか、メモリを増設します。その後、ストレージやネットワークの設定に手を加える前に、同じPlexワークロードを再テストしてください。
同じメディア経路でストレージをテストする
ストレージを確認するには、症状が再現している間に、同じファイルシステムから同じメディアを読み出し、デバイスのレイテンシ、キューイング、I/O待機を監視します。容量と性能は別の問題です。ディスクに空き容量があっても、別のジョブがランダムI/Oを発生させていたり、メディア経路が負荷の高いプールやネットワークマウントの背後にあったりすると、応答が遅くなることがあります。
iostatやiotopなどのLinuxツールが役立つのは、ディスクI/O待機とデバイスのスループットによって、高いCPU使用率やスワップ動作とは異なる障害モードが分かるためです。これらの数値はアイドル時の平均値ではなく、正確なバッファリングの発生時間帯と照らし合わせてください。
Plexがバッファリングしている間もファイルを正常に読み取れているなら、ストレージの可能性は低くなります。症状と同時にレイテンシとキューイングが上昇するなら、競合しているディスクジョブを一時停止するか、テストファイルを既知の高速なローカルパスに移動してください。同じ再生モードでPlexがすぐに回復すれば、ストレージは疑いの段階から証拠の段階へ移ります。
実際の経路でネットワークスループットをテストする
Plexとは別に、サーバーとクライアント間の経路をテストします。ローカルの有線クライアントを使えば、リモート経路の問題とサーバー全体のリソース問題を切り分けられます。また、エンドツーエンドのスループットテストによって、Plexアプリケーションに依存せず、その経路がメディアのビットレートを維持できるか確認できます。
両端を管理できる場合は、iperf3などのツールを使用します。ネットワークテストでは、スループット、パケット損失、レイテンシを確認してください。公称リンク速度が高くても、実際の経路で安定したアプリケーション通信が行えるとは限らないためです。
CPU、メモリ、ストレージが健全なまま独立したネットワークテストの結果だけが低下するなら、トランスコーダーを調整する前に経路を修正します。ネットワークに十分な継続的余裕があり、有線のローカルテストでもPlexの症状が続く場合は、より高速なルーターを購入するのではなく、サーバーリソースの分岐に戻ってください。
テストで失敗したリソースだけを変更する
切り分けテストで最初に失敗したリソースを選び、その分岐だけに影響するはずの変更を1つ行います。たとえば、計算リソースが原因のストリームに対して検証済みのハードウェアトランスコードを有効にする、メモリを大量に消費するバックグラウンドジョブを減らす、ディスク負荷の高いタスクを別の時間帯に移す、弱いネットワーク経路を迂回するといった方法があります。
Plex固有の追加対応については、ZimaSpaceのバッファリング診断手順を参照してください。再生モード、変換負荷、ネットワークの安定性、ストレージの応答性のうち、どの分岐を変更すべきかが分かった後に、さらに詳しく確認できます。
変更後は、元と同じファイル、クライアント、再生モードで再テストします。元の症状が改善し、それに対応する負荷シグナルが低下するか、余裕が増えた場合にのみ、そのコンポーネントをボトルネックと判断してください。症状が変わらない場合は、基準状態に戻して次の分岐をテストします。実際の原因が偶然消えるまでアップグレードを重ねてはいけません。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
