バックグラウンドジョブ用に Plex が確保すべき空き容量はどのくらいですか？
Plexでは、すべてのサーバーに共通する空き容量ルールを設定すべきではありません。確保しておくべき容量は、通常発生する最大の一時処理、予想されるメタデータの増加量、そしてファイルシステムをいっぱいにすることなくメンテナンスを完了したり、失敗した変更から復旧したりするための余裕を合わせたものです。
小規模なライブラリをDirect Playするだけのサーバーと、プレビューサムネイルの生成、複数ストリームのトランスコード、DVR処理、メタデータの再構築を行うサーバーでは、ストレージの使われ方が異なります。まず、バックグラウンド処理を1サイクル完全に実行したときの使用量と、代表的な最大トランスコードの使用量を測定してください。そのうえで、適当な10%、20GB、100GBといったルールをそのまま使うのではなく、観測したピークを上回る空き容量の下限を設定します。
共通の空き容量から始めない
Plexが一時データや永続データをどこに書き込むかを考慮しない空き容量の助言は、誤解を招きます。メディアアレイにはテラバイト単位の空きがあっても、変換処理やメンテナンス中に、より小容量のシステム用ファイルシステムやアプリデータ用ファイルシステムが容量不足になることがあります。
Plexの説明によると、トランスコードでは一時ディスクストレージが使用され、デフォルトではオペレーティングシステムのディスクに保存される場合があります。そのため、メディアプール全体の容量よりも、実際のトランスコード先の空き容量のほうが重要です。
固定の空き容量を使う場合でも、自分のワークロードで測定した場合に限り、最初の仮説として扱ってください。最初に設定すべき有用な閾値は、別のライブラリ、ビットレート、ファイルシステムから借りてきた数字ではなく、自分のバックグラウンド処理が不安定になる空き容量の下限です。
Plexのどの処理が一時容量または永続容量を実際に消費するか測定する
Plexがアイドル状態のときやメンテナンスを実行しているときに増加する可能性のある場所を追跡します。アプリデータディレクトリ、トランスコード用一時ディレクトリ、プレビューサムネイルデータ、データベースのバックアップ、実際に使用しているダウンロード用またはDVR用の作業領域などです。これらは異なるファイルシステム上に存在する可能性があるため、それぞれ個別に測定してください。
動画プレビューサムネイルは、短時間だけ発生する増加ではなく、継続的に増え続けるデータの原因になることがあります。Plexによると、一般的なサムネイルインデックスは、1つのライブラリアイテムだけで数十MBを消費することがあり、動画の長さによっても変わります。そのため、大規模なライブラリでは、1アイテムあたりの小さなコストがアプリデータの大幅な増加につながる可能性があります。
完全なスケジュールタスクの実行時間、代表的なメディアを追加するライブラリスキャン1回、通常発生する最大のトランスコードの前後で容量を測定します。処理中の一時的な増加のピークと、処理後に残る増加の両方を記録してください。処理後に残る増加がデータの成長分であり、それを超えたピーク分が作業領域です。
観測した最大の処理量を使って最初の下限を設定する
最初の下限を設定する際は、観測した最大の作業領域増加量を構成要素として使います。代表的なトランスコードで一時ファイルシステムに数GBが必要になる場合や、サムネイル生成中にメンテナンス用のアプリデータが増加する場合、その観測ピークを確保容量に含めてください。
RAM上でのトランスコードによって容量の問題がなくなると考えてはいけません。実用的なPlexのRAMトランスコード環境でも、一時トランスコードディレクトリには、実行中のワークロードに十分な使用可能容量が必要です。パスを移動すると、サイズを見積もる対象のリソースが変わるだけで、一時容量そのものが不要になるわけではありません。
計画時には、測定した下限を次の式で定義します。最大の通常時一時ピーク + 次回のクリーンアップまでに予想される永続的な増加量 + 変動に備えた安全マージン。この式は運用上の基準であり、Plexが公開している固定値ではありません。バックグラウンドで使用するストレージ量が大きく変わる機能を有効にした場合は、再計算してください。
同時実行される処理と復旧のための余裕を追加する
サーバーで複数の処理が日常的に重なる場合、1つの処理だけを実行するケースが最悪とは限りません。サムネイル生成、データベースメンテナンス、バックアップ、ダウンロード、トランスコードが同じファイルシステムを共有することがあり、アップグレード時には新しいイメージやロールバック用コピーのために一時的な追加容量が必要になる場合もあります。
現実的に重なる可能性がある最大の処理を、ファイルシステムの障害発生限界に達することなく完了できるだけの余裕を追加してください。2つの処理がスケジュールによって決して重ならないなら、ピークを合算する必要はありません。頻繁に重なるなら、推測するのではなく、その同時実行時の容量を測定します。
復旧用の容量は、メディアライブラリの容量とは別の概念として確保してください。メディアプールが満杯になる場合と、アプリデータ用ディスクが満杯になる場合では、発生する障害が異なります。Plexの状態を保存しているファイルシステムには、バックアップの作成、一時ファイルの書き込み、失敗したメンテナンス変更の取り消しができるだけの容量を残してください。
ドライブが満杯になる前に容量不足の兆候を確認する
空き容量が少なくなると、通常は新しい書き込みを必要とする処理に兆候が現れます。変換が開始できない、バックグラウンド処理が完了しなくなる、データベースやログを拡張できない、オペレーティングシステムがファイルシステムの容量不足を報告するといった症状です。空き容量がゼロになるまで待ってから、容量の問題として扱わないでください。
Plexユーザーの報告では、制限された一時保存先が処理中に満杯になると、録画や変換が失敗することが確認されています。そのため、メディアアレイに十分な容量が残っていても、小容量のRAMディスクやアプリ用パーティションでは処理に失敗することがあります。書き込みは、その処理でPlexが実際に使用しているファイルシステム上で成功しなければならないためです。
処理が失敗した場合は、失敗した正確な時刻の空き容量とパスを記録してください。他の条件を変えずに一時パスを移動したり容量を追加したりすることで同じ処理が成功したなら、その空き容量の閾値は推測ではなく証拠になります。
Plexがメンテナンスサイクルを完全に完了できない場合は下限を引き上げる
1回の完全なメンテナンスサイクルと、代表的な高負荷の再生時間を通して測定します。空き容量が最も少なくなった時点、その原因となった処理、処理後にファイルシステムが安定した基準値へ戻ったかどうかを記録してください。異常な一度きりの処理が恒久的な確保容量を決めてしまわないよう、もう一度繰り返します。
ZimaSpaceのバックグラウンドストレージの圧迫に関するガイドは、スキャンやバックアップなどの処理がPlexとディスクリソースを競合している場合に役立ちます。メンテナンス時間が長くなり、容量も大量に消費するようになった場合は、容量とI/Oパフォーマンスを併せて確認してください。
通常の処理が現在の確保容量に繰り返し近づく場合、永続的なメタデータの増加によって余裕が徐々に失われる場合、または復旧処理に必要な容量を確保できなくなった場合は、空き容量の下限を引き上げるか、ワークロードを移動してください。適切な下限とは、予想される最も負荷の高いサイクルを完了でき、なおかつ検証済みの復旧手段を残せる値です。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
