PlexがCPU、メモリ、ストレージ、ネットワークのどれに制約されているかをテストする方法
Plexのボトルネックは、最も忙しいグラフではありません。同じ再生やインターフェースの症状を繰り返し引き起こす、余裕が失われたリソースです。
正確なテストは、1つのファイル、クライアント、再生モード、時間帯から始め、条件を変えずにCPU、メモリ、ストレージ、ネットワークを測定します。使用率が高いだけでは、根拠として不十分です。症状とともに負荷が上昇し、そのリソースに対する制御された変更によって元のリクエストが改善した場合にのみ、そのリソースが主なボトルネックだと判断できます。
再現可能なPlexワークロードを1つに絞る
問題を再現する最小限のリクエストを選びます。バッファリングする1つのダイレクトプレイファイル、処理が遅れる1つのトランスコード、または停止する1つのライブラリアクションなどです。後で取得するメトリクスが同じジョブを示すように、クライアント、選択したトラック、画質、ネットワーク経路、同時実行中のバックグラウンドジョブを固定します。
有効な調査は症状から始め、各サブシステムを順番に確認します。一般的なLinuxのワークフローでも、1つの高い使用率だけを答えとみなさず、同様にリソースの圧迫を切り分けます。
遅延が発生した時刻と、収集したメトリクスの時刻を記録します。実行ごとに症状が移動したり消えたりする場合は、再現するまでワークロードを単純化してください。そうしないと、あるタスクによるディスクスパイクを、別のタスクが原因のPlex遅延と誤って結び付ける可能性があります。
CPU負荷とメモリ負荷を切り分ける
CPU負荷が疑わしいのは、Plexプロセスやトランスコーダーが継続的に計算リソースを消費し、処理が遅れ続ける場合です。メモリ負荷は異なります。利用可能メモリが減少し、メモリ回収が増加したりスワップが発生したりすると、CPUが完全に飽和していなくても応答時間が悪化します。
topやvmstatなどのツールは、CPUとメモリには異なる指標が必要です。ランキュー、CPU時間、空きメモリまたは利用可能メモリ、ページング、スワップアクティビティは、単独のスクリーンショットではなく、同じPlexイベントと合わせて確認します。
変更するのは1つの分岐だけにします。オプションのソフトウェアトランスコードを停止する、または検証済みのアクセラレーション経路を有効にして計算処理をテストします。メモリをテストする場合は、メモリを大量に消費するサービスを一時停止するか、一時的に余裕を増やします。元のPlexの症状が予想どおり変化した場合にのみ、そのリソースが確認されたと判断できます。
同じリクエストでストレージの遅延とスループットをテストする
ストレージプールに十分な空き容量があっても、ストレージが限界になることがあります。別のジョブがキューを発生させている間、Plexはメディアの読み取り、メタデータ、データベース処理、またはトランスコード用の一時領域で待機している可能性があります。比較すべきなのは、正常な実行時と失敗時における、まったく同じメディア経路です。
ディスク診断には、スループットだけでなく遅延とキューの挙動も含める必要があります。実用的なI/O監視では、デバイスの遅延、使用率、キュー深度を確認し、表示上のMB/sが控えめでもリクエストが待機しているかどうかを判断します。
競合するバックアップを一時停止するか、クライアントを変更せずにテストファイルを既知の高速なローカルパスへコピーします。CPU、メモリ、ネットワークが同程度のまま同じPlexリクエストが回復した場合、ストレージは疑いの段階から、制御された結果へと進みます。
サーバーとは独立してネットワークをテストする
CPUとストレージが正常でも、実際の経路がメディアのビットレートを維持できなければ、ダイレクトプレイのセッションはバッファリングすることがあります。可能であれば、リモート配信の前にローカルの有線配信をテストし、その後、経路を個別に測定します。Plex自体をワークロードと測定ツールの両方にしないことが重要です。
スループットが低下し、パケット損失や再送が増加し、サーバーリソースに余裕がある状態で遅延が不安定になる場合、ネットワークのボトルネックが有力になります。1回の使用率スナップショットで判断するのではなく、負荷が影響と相関している場合、そのリソースがボトルネックである可能性が高くなります。
独立した有線経路に十分な余裕があり、それでもPlexが失敗する場合は、計算処理またはストレージに戻って確認します。同じ時間帯に経路自体が限界に達している場合は、トランスコーダー、データベース、メモリ割り当てを変更する前に、問題のある経路を修正します。
疑わしいリソースを1つだけ変更して再実行する
最後の手順は、ダッシュボードをもう一度確認することではなく、原因を見分けるためのテストです。最も強い根拠があるリソースを選び、その分岐だけに影響する、元に戻せる変更を1つ行います。バックアップを一時停止する、競合するコンテナの負荷を下げる、有線ローカルクライアントを使用する、強制変換を解除する、といった方法です。
Plexの再生モードは重要です。ダイレクトプレイ、ダイレクトストリーム、トランスコードでは、サーバーにかかる負荷が異なります。互換性によってメディア経路が変わるため、クライアントや画質を変更すると、同じファイルでもボトルネックが移動することがあります。
単一の変更後に元のワークロードを再実行し、症状とリソースのシグナルの両方を比較します。Plexに特化した続きの手順が必要な場合は、CPU、メモリ、ストレージ、ネットワークのテストを使うと、修復手順を実際に問題が発生したリソースに結び付けられます。
おすすめ商品
テック＆AIハブ
もっと読む
Plexの状態とは何か、どの部分を永続化する必要があるのか？
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。
Plexはローカルセッションとリモートセッションで認証をどのように処理しますか？
Plexの認証はサーバーとアカウントの識別から始まり、その後、ローカルまたはリモートのネットワーク経路によって到達可能性と安全な接続の動作が決まります。
ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか？
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。
