共有リソースが複数アプリ対応のホームサーバーにおけるPlexのパフォーマンスに与える影響
別のサービスが同じCPU、メモリ、ストレージ、アクセラレーター、またはネットワーク経路を取り合うと、複数のアプリを動かすホームサーバー上でのPlexの動作は変化します。
多くのホームサービスは同じタイミングでピークに達しないため、ハードウェアの共有は効率的なことが多い一方、平均使用率だけでは短時間の競合を見落とす可能性があります。重要なのは、Plexに専用ボックスが「必要かどうか」ではありません。実際に処理が重なる時間帯に、どの共有リソースの余裕が十分に失われ、起動、シーク、トランスコード、ブラウジング、または再生の信頼性に影響するかです。
ワークロードが重なるまでは、ハードウェアの共有は効率的
1台のホームサーバーでメディア、バックアップ、自動化、写真、ダウンロード、小規模なWebアプリケーションを実行すれば、負荷の低いマシンを複数台使うよりも、アイドル状態のハードウェアを効率的に活用できます。統合が問題になるのは、単独では問題のないワークロードが、同じリソースを同じタイミングで必要とするときだけです。
ホームサーバーの計画では、各サービスを、それぞれ固有のコンピュート、メモリ、ストレージ、ネットワーク特性を持つワークロードとして扱うほうが効果的です。一般的なホームサーバーのアーキテクチャモデルでは、1つのアプリケーション名だけを基準にマシンの規模を決めるのではなく、ワークロードの強度ごとにサービスを分類します。
アプリの一覧ではなく、繁忙時間帯のマップを作成しましょう。Plexの視聴と重なるサービス、各ピークが続く時間、使用するリソースを記録します。午前3時のバックアップは、スケジュールや所要時間が実際に視聴時間帯と重ならない限り、夜間のダイレクトプレイの余裕を減らしません。
CPUとメモリの競合は、ホスト全体が満杯になる前にタイミングを変える
CPUの競合が起きると、長時間の平均使用率が許容範囲に見えても、トランスコード、サムネイル生成、データベース処理が遅れることがあります。メモリの圧迫はより気付きにくい場合があります。複数のコンテナが余裕を持って収まっていても、ワーキングセットが重なるとメモリの再利用が増えたり、スワップによって高速なリクエストがストレージ処理に変わったりします。
共有リソース環境では、マシン全体が枯渇しているように見える前にパフォーマンスが変化することがあります。コンテナごとのCPUとメモリ使用量をPlexで発生している症状と照らし合わせて追跡すれば、長時間のホスト平均がまだ余裕のある状態でも、短時間の急増を確認できます。
プロセスごとのCPU使用率、メモリ圧迫、競合しているサービスを確認しながら、同時にPlexの症状を測定します。ストレージやネットワークの条件を変えずに1つのコンテナを停止すると元のタイミングに戻る場合、コア数や搭載RAMだけを根拠にした判断よりも、因果関係が強いと考えられます。
ストレージI/Oによって、Plexはバックアップやダウンロード処理の影響を受ける
Plexのメディア読み取りはシーケンシャルになることがありますが、データベース、メタデータ、サムネイル、ログはより小さなI/Oを発生させます。そのため、バックアップ、ダウンロードの展開、パリティ処理、写真のインデックス作成、仮想ディスクなどが、Plex単独のテストでは現れない形で干渉する可能性があります。
インタラクティブな処理を保護する実用的な方法の1つは、新しいハードウェアを購入する前に優先度やスケジュールを変更することです。Ubuntu上のPlex環境では、プロセスの優先度を設定して干渉を減らすことができます。ただし、正確な仕組みは普遍的な解決策とみなさず、ホスト上でテストする必要があります。
他のジョブが実行されているときだけストレージのレイテンシーが上昇するなら、データベースやスクラッチ領域をより低レイテンシーのストレージ層へ移す、負荷の高いジョブを別の時間帯に変更する、またはスループットを制限してみましょう。こうした簡単な制御を同じワークロードで繰り返し試しても改善しない場合に限り、ストレージを分離します。
ネットワークとアクセラレーターの共有は、異なる干渉パターンを生む
バックアップやファイルコピーによってネットワークリンクが飽和している一方で、ホームサーバーのCPUには余裕があることがあります。また、GPUのエンコーダー容量に余裕があっても、メモリ、デコード段階、別のアプリケーションによって利用可能なメディア処理パイプラインが変化する場合があります。これらは異なる制限であり、一般的な「サーバー負荷」という1つの数値にまとめるべきではありません。
ネットワークとアクセラレーターの負荷は、CPUやメモリとは別に測定する必要があります。ホスト全体にまだ余裕がある状態でも、症状が現れることがあるためです。ネットワークリンクの飽和、GPUメモリの枯渇、競合するデコード処理は、CPU不足と同じものではありません。
実際に共有されているリソースをテストしましょう。ネットワークの場合は、転送が混雑している状態を再現しながらPlexのスループットを確認します。GPU処理の場合は、別のアクセラレーター処理が動作している状態で、実際と同じトランスコードの組み合わせを再現します。競合するジョブとPlexの症状が連動して変化する場合にのみ、分離を検討します。
繰り返し競合するリソースだけを分離する
競合への最初の対応は、最小限で元に戻しやすい変更にすべきです。バックアップのスケジュール変更、ダウンロード速度の上限設定、データベースのSSDへの移動、メディアアクセラレーターのPlex専用化、または1つのサービスがホストの容量を使い切らないようにコンテナのリソース制限を適用する、といった方法です。2台目のマシンを導入すると、消費電力、パッチ適用、ネットワーク依存関係、復旧経路が増えるため、明確な競合を解決する目的で導入すべきです。
十分な余裕を確認できれば、Plexと他のサービスを1つのシステムに統合できます。ある実測環境では、複数のサービスとPlexを同時に実行しても十分な性能を維持できました。ただし、その結果はテストしたハードウェアとワークロードに当てはまるものであり、すべてのホームサーバーに当てはまるわけではありません。
より簡単な制御を行っても、ワークロードの重複によって同じリソースが繰り返し機能不全に陥るなら、専用メディアサーバーと共有メディアサーバーの境界を比較しましょう。繁忙時間帯を乗り越えられるなら1台にまとめ、測定された競合、または家庭で受け入れられない保守上の依存関係を分離によって解消できる場合にのみ、分割します。
おすすめ商品
テック＆AIハブ
もっと読む
Plexの状態とは何か、どの部分を永続化する必要があるのか？
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。
Plexはローカルセッションとリモートセッションで認証をどのように処理しますか？
Plexの認証はサーバーとアカウントの識別から始まり、その後、ローカルまたはリモートのネットワーク経路によって到達可能性と安全な接続の動作が決まります。
ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか？
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。
