Plexはダイレクト再生の品質が低下する前に、同時処理をどれくらいこなせる？
Plexには同時実行タスク数の一律の上限はありません。Direct Playの品質が低下するのは、同時に動作する処理が、メディア配信に必要なリソースの余裕を消費した場合だけです。
ライブラリのスキャン、バックアップ、写真インデクサー、ダウンロードクライアント、仮想マシン、トランスコードは、いずれもPlexと並行して実行できますが、必要なリソースは同じではありません。したがって、重要なのはタスク数ではありません。競合するワークロードが存在する状態で、既知のDirect Playセッションの起動、シーク、またはバッファリングの余裕が失われる、再現可能な最初のポイントです。
同時実行処理はタスク数ではなくリソース需要で定義する
まず、同時に実行するジョブを、実際に消費するリソースごとに分けます。メタデータのスキャンでは小さなファイルの読み取りやデータベース処理が発生し、バックアップではシーケンシャルI/Oが大きな負荷になることがあります。また、動画のトランスコードでは、継続的な計算処理やアクセラレーターの処理能力が必要になる場合があります。これら3つをすべて「1タスク」と数えると、サーバー内のどの部分で競合しているのかが見えなくなります。
実用上の上限は、一定数のプロセスが存在した時点ではなく、需要が共有リソースの容量に達した時点で現れます。CPU時間、利用可能なメモリ、ストレージI/O、ネットワークスループットにはそれぞれ固有の容量があるため、全体の使用率を1つの数値で判断するのではなく、リソース制限を個別の指標で確認する必要があります。
ワークロードを、1つのDirect Playセッション、1つのバックアップ、1つのスキャン、2つのコンテナ、といった組み合わせで記録します。こうしておけば、後から同じ条件を再現でき、テストを恣意的なバックグラウンドプロセス数ではなく、実際の家庭内での使い方に結び付けられます。
余裕を測定する前にDirect Playの条件を固定する
まず、確実にDirect Playできるファイルとクライアントを1つ選び、音声、字幕、画質、ネットワーク経路を変更せずに保ちます。セッションが気付かないうちにトランスコードへ切り替わると、テスト対象が変わってしまい、Direct Playの経路がどれだけの同時処理に耐えられるのか判断できなくなります。
Direct Playは、サーバーのCPUだけでなく、クライアントの互換性と配信能力にも左右されます。そのため、安定した基準値を作るには、競合するタスクを追加する前に、元のファイルが互換性を維持していることと、ネットワークに実際のビットレートに対する十分な余裕があることを確認します。
起動時間、代表的なシーク、継続再生、サーバーのCPUとメモリ、ストレージレイテンシ、ネットワークスループットを記録します。これらの基準値があれば、後で発生した遅延を、「Plexの調子が悪くなった気がする」といった曖昧な印象ではなく、比較可能な変化として評価できます。
バックグラウンド処理を1層ずつ追加する
視聴中に重なる可能性のある実際のジョブを追加しますが、組み合わせを試す前に1つずつ追加してください。まず、スケジュールされたライブラリ処理やバックアップなど、最も一般的な重複処理から始め、同じ再生要求を繰り返します。セッションが問題なく継続する場合は、いきなり合成した最大負荷に進むのではなく、次に現実的なジョブを追加します。
Direct Playのストリームは通常、トランスコードより軽量ですが、それでもストレージとネットワークによる配信処理は必要です。高ビットレートの4Kは、サーバーが動画を再エンコードしていなくても、Direct Playが実際のリソースを消費する理由を示しています。そのため、計算処理のボトルネックがなくても、ストレージやネットワークの競合によって再生品質が低下することがあります。
追加した各ジョブは、通常の定常状態に達するまで十分な時間を継続します。10秒だけ実行するバックアップや、すでに完了したスキャンでは、実際に夜の視聴時間帯と重なるワークロードと同じ競合を明らかにできません。
最初に余裕を失う共有リソースを監視する
ユーザーが初めて変化を認識した時点をタイムスタンプとして記録し、その前後のリソース指標を比較します。CPUスパイクは、計算処理も遅延している場合にのみ重要です。メモリ使用量の高さは、メモリの回収やスワップによってレイテンシが変化した場合に意味を持ちます。ストレージとネットワークについては、グラフが忙しそうに見えるかどうかではなく、キュー、レイテンシ、スループットの証拠を確認する必要があります。
重要な概念は、共有リソースをめぐる競合です。複数のジョブが同時に同じCPU、メモリ、ディスク、またはネットワーク経路を必要とすると、サーバーの他の部分がアイドル状態に見えていても、応答時間が増加することがあります。
競合していると考えられるジョブを一時停止し、同じDirect Play要求を繰り返します。再生がすぐに基準値へ戻り、それと同時に対応する負荷の指標が低下するなら、同時実行の境界を示す証拠が得られつつあります。何も変化しない場合は、ワークロードを元に戻し、推測でアップグレードするのではなく、次の共有リソースを調べます。
観測した失敗点を容量の境界に変換する
有用な容量の説明では、ワークロードと、問題が発生したリソースを明示します。たとえば、通常のコンテナとスキャンを実行していても、既知のDirect Playストリームは安定しているが、バックアップを開始するとストレージレイテンシが上昇してシークに失敗する、といった具合です。これは「Plexは6タスク処理できる」という説明よりも、他のサーバーでも応用しやすい情報です。
非常に大規模なPlex環境を見ると、セッション数だけでは普遍的な上限にならない理由が分かります。40～50の同時セッションを処理できる環境では、ダイレクトストリーム、トランスコード、ネットワーク容量、ハードウェア構成が、小規模なホームサーバーとはまったく異なる場合があります。
再現可能な最初の失敗点より下に安全マージンを設け、ワークロードを大きく変更した後は再テストします。特に、混在するクライアントでもDirect Playを維持したい場合は、混在クライアントでのDirect Playの境界を利用して、互換性の変化と共有リソースの飽和を切り分けます。
おすすめ商品
テック＆AIハブ
もっと読む
Plexの状態とは何か、どの部分を永続化する必要があるのか？
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。
Plexはローカルセッションとリモートセッションで認証をどのように処理しますか？
Plexの認証はサーバーとアカウントの識別から始まり、その後、ローカルまたはリモートのネットワーク経路によって到達可能性と安全な接続の動作が決まります。
ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか？
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。
