1台のホストがボトルネックになる前に、Plexライブラリはどれほど大きくできる？

すべてのPlexライブラリに適用できる有用な一律のサイズ上限はありません。データベース、スキャン、ストレージ、または復旧の目標を満たせなくなった時点で、1台のホストでは力不足になります。

同じアイテム数のライブラリでも、メタデータの深さ、プレビュー生成、ストレージの遅延、CPU、同時実行される処理が異なるため、動作は変わります。恣意的な数値を待つのではなく、ライブラリの成長に伴って増える処理を追跡しましょう。通常のメンテナンスやブラウジングがサービス目標を満たせなくなったところが、実用上の限界です。

ライブラリの成長に伴うデータベース応答を追跡する

ライブラリが成長すると、Plexが検索・維持しなければならないインデックス済みの状態が増えます。正常なデータベースは大規模になっても応答性を維持できますが、低速なストレージや蓄積したメンテナンス上の負債によって、より小規模なライブラリのほうが悪く感じられることもあります。

Plexデータベースのメンテナンスは、ライブラリの状態が拡大し、アクセスパターンが複雑になるにつれて重要です。

ライブラリの規模が一定の節目に達するたびに、同じクライアントとウォーム状態のテストを使い、検索・ブラウジングの遅延とデータベースサイズを記録します。CPUとネットワークがアイドル状態なのに遅延が急増する場合は、サーバーを分割する前にアプリデータのデータベースパスを調査してください。

メタデータの容量は想定を超えることがある

ポスター、アートワーク、インデックス、プレビュー、解析データによって、Plexサーバーのディレクトリはメディアのアイテム数から想定されるよりもはるかに速く増大することがあります。このアプリデータの容量は、メディアを別のストレージに保存している場合でも、バックアップにかかる時間や復元計画に影響します。

大規模なPlexデータベースは、実際の環境で数GBに達することがあるため、アイテム数だけでは容量のしきい値として不十分です。

メインのデータベースファイルだけでなく、Plexのデータディレクトリ全体とバックアップにかかる時間を測定してください。バックアップまたは復元の時間枠が復旧目標に収まらなくなった場合は、ライブラリの機能を追加する前にストレージまたはバックアップの設計を変更します。

スキャン時間は運用上の限界になる

完全スキャンや部分スキャンに時間がかかりすぎると、ユーザーの利用や他のメンテナンス処理と重なる可能性があります。ボトルネックは、ファイルシステムの列挙、メタデータ処理、データベース更新、またはネットワークストレージの遅延かもしれません。

アプリデータと大量のメディアを分離することで、メタデータのI/Oと大容量メディアの読み取りに異なるストレージパスを使用できます。

制御されたスキャンの所要時間を測定し、同時にCPU、アプリデータのI/O、メディアパスのI/O、データベースの遅延を記録します。共有パスの1つが飽和したことでスキャン時間が伸びている場合は、2台目のPlexホストを追加する前に、その依存関係を解消してください。大量のメディアとアプリケーションの状態を分離するNASメディアセンター構成なら、Plexデータベースを同じ高遅延パスに置かずに容量を拡張できます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

最終的な容量テストには復旧時間を使う

障害からの復旧が家庭やサービスの目標を満たせなくなった時点で、ライブラリは1台のホストにとって運用上大きすぎます。すばやくブラウジングできるサーバーでも、復元に数日かかるなら、現在の設計ではすでに限界を超えている可能性があります。

Plexの状態移行では、メディアへのアクセスだけでなく、データベース、メタデータ、設定、パスの継続性も維持する必要があります。

別のストレージまたはテストホストへの復元リハーサルを実施し、ライブラリを利用可能な状態に戻すまでの時間を記録します。バックアップを調整しても復旧時間が目標を超える場合は、次の成長段階に入る前に、役割を分割するか状態データのストレージを改善してください。