1台のPlexホストに安全な同時処理数の上限を設定する方法

Plexホストは、ストリーム数の一律な基準ではなく、実測した同時実行数の予算内に収まるユーザー数とバックグラウンドジョブ数を処理できるようにする必要があります。

ダイレクトプレイ、ハードウェアトランスコード、ソフトウェアトランスコード、スキャン、バックアップ、関連コンテナは、それぞれ異なるリソースに負荷をかけます。自宅で実際に重なる作業の組み合わせをもとに予算を立て、いずれかのリソースがユーザーに見える障害のしきい値に繰り返し達するようになったら、作業の追加を止めましょう。

ユーザー数を数える前にセッションの種類を分ける

ダイレクトプレイのユーザー1人と、4Kのソフトウェアトランスコードを行うユーザー1人とでは、サーバーにかかる負荷は同じではありません。クライアントの互換性や字幕の動作によって、同じメディアでもネットワークとストレージへの軽い負荷から、演算処理の重い負荷に変わることがあります。

特定のテスト環境では、N100はCPU負荷を比較的抑えながら複数のハードウェアトランスコードを同時に処理できましたが、この結果を一般的なユーザー数の上限として扱うべきではありません。

想定される最も負荷の高いセッションを、ダイレクトプレイ、ハードウェアトランスコード、ソフトウェアトランスコードに分類します。各セッションが実際にどのリソース経路を使うかを把握してから、ユーザー数を数えましょう。

バックグラウンドジョブも含めてピーク時のテストを行う

ライブラリのスキャン、ダウンロード、バックアップ、その他のコンテナによって、再生テストでは問題のなかったホストでもリソースの競合が起きることがあります。そのため、同時実行数の予算には視聴者とジョブの両方を含める必要があります。

他のサービスの応答性を保つ必要がある一方で、コンテナが利用可能なCPU、メモリ、ブロックI/Oを使い切る可能性があるため、ホームラボではリソース制御が必要です。

想定される視聴者の組み合わせで、通常のバックグラウンドタスクを1つ実行しながらテストし、次にそのタスクを停止して同じテストを繰り返してください。その差から、CPUコアを単純に増やすよりも、スケジューリングや分離が有効かどうかがわかります。

メンテナンスと復旧のための余裕を確保する

再生のピーク時をかろうじて乗り切るホストには、アップデート、データベースのメンテナンス、バックアップ、一時的なソフトウェアトランスコードへの切り替えに対応する余裕がありません。ストリームの再生に失敗する前でも、これは運用上の限界です。

リソースごとの飽和度チェックにより、必要な処理が重なる時間帯にCPU、メモリ、ストレージ、ネットワークでキューの滞留やエラーが継続した場合を、予算上の測定可能な停止基準として設定できます。

再生の安定性、タスクの完了、復旧時間について、合格基準を定めてください。通常のメンテナンス作業を1つ実行しただけでサーバーがすぐにその限界を超えないよう、十分な余裕を持たせてください。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

予算の拡大が難しくなったら役割を分離する

1台のホストでユーザー数を増やすことが、常に次の最善策とは限りません。ストレージ、バックアップ、または負荷の高い併用サービスが繰り返し制約になる場合、その役割を分離するほうが、マシン全体を買い替えるより効果的なことがあります。

したがって、Plexのハードウェア要件では、「最大ユーザー数」という単一の数値ではなく、ストリームの組み合わせ、アプリデータの保存先、ネットワーク、併用するワークロードを考慮する必要があります。

合意した許容範囲内で複合テストを通過するなら、1台のホストを使い続けてください。同じ測定上のボトルネックが続き、両方のワークロードを同時に実行する必要がある場合は、演算処理またはストレージを分離してください。