Plexのキャッシュとトランスコード用一時ストレージを設定する方法
Plexの永続的なアプリデータは信頼性の高いストレージに保存し、トランスコードの一時ファイルは十分な空き容量のある高速なローカルパスに配置してください。一時出力をメディアフォルダーに混在させないでください。
Plexの「キャッシュ」と「トランスコード一時ディレクトリ」は異なる問題を解決します。サーバーデータディレクトリには、永続的なデータベースやメタデータに加えてキャッシュ用サブディレクトリが含まれます。一方、トランスコーダーの設定は、一時的なストリーミングセグメントの書き込み先を制御します。Dockerホームサーバーでは、それぞれの役割を意図的に割り当ててください。これにより、構成データベースを危険にさらすことなく高速なスクラッチ領域を変更でき、また一時パスがいっぱいになっても、Plexがコア状態を正常に維持するために必要なボリュームを圧迫せずに済みます。
永続的なアプリデータと破棄可能な一時作業を分離する
Plexの構成用マウントは永続状態として扱ってください。コンテナを再作成しても保持され、通常のバックアップ対象になる必要があります。その中のキャッシュは破棄しても問題ありませんが、データベースとメタデータは失われてはなりません。そのため、サムネイルやトランスコードを高速化する目的だけで構成ツリー全体を揮発性の場所へ移すのは、誤った最適化です。
Plexは、サイズが過大になったサーバーデータディレクトリは、重要度の低いデータを除外または移動することで縮小できる場合があると説明しています。また、サーバーデータサイズに関するガイダンスでは、データディレクトリとメディアストレージを明確に区別しています。この区別を利用して、復旧に不可欠なパスを整理しておきましょう。
現在のDockerテンプレートで構成用パスが1つしかマッピングされていない場合は、まずそのマッピングを維持してください。トランスコード用のスクラッチパスは別途追加または変更し、Plexのデータベースを同時に移動することなく、性能と容量をテストできるようにします。
トランスコードディレクトリは、まず容量、次に速度で選ぶ
Plexの高度なトランスコーダー設定では、ストリーミングトランスコード用の一時ディレクトリを選択できます。このパスには、アクティブなセッションによって作成される一時セグメントを保存できる十分な空き容量が必要です。高速なSSDやNVMeストレージは遅延を減らせますが、大規模なトランスコードで満杯になる小容量の高速ボリュームよりも、やや低速でも安全な余裕を持つローカルボリュームの方が適しています。
公式のPlexトランスコーダーのドキュメントでは、トランスコード一時ディレクトリにネットワーク共有、メディアライブラリのパス、または無関係なデータがすでに存在する場所を使用しないよう警告しています。Plexは、元のファイルとおおむね同程度の空き容量に加えて、さらに余裕を確保することも推奨しています。したがって、現実的に想定される最大の同時実行負荷に合わせてスクラッチパスの容量を決めてください。
メモリバックの一時ストレージを使用する場合は、容量を厳格な上限として扱い、他のサービスも計算に含めてください。RAM上のパスは高速ですが、大規模または同時実行のトランスコードによって、NAS全体のメモリ不足を招く可能性があります。RAMを使用する明確な理由を測定で確認できるまでは、ローカルSSDまたはNVMeから始めてください。
ホストとコンテナが同じ場所を認識するようDockerパスをマッピングする
Dockerでは、コンテナ内でPlexが認識するパスを、意図したホストストレージにマッピングする必要があります。マウント先が間違っていると、ホスト側のディレクトリに十分な空き容量があっても、コンテナは別の場所に書き込むことがあります。Plexのトランスコーダー設定を変更する前に、マッピングの両側を確認してください。
ZimaOSで最初のDockerアプリを実行するためのガイドは、ZimaOSでアプリボリュームを考える際の有用な基準になります。アプリケーションから見えるのは公開されたコンテナパスだけであり、それらのパスをホスト上のどこに配置するかはNAS管理者が決める必要があります。
マッピングが正しく設定できたら、トランスコードを強制的に実行し、ホスト側のディレクトリを監視してください。再生中は、そこに新しい一時ファイルが表示されるはずです。構成ボリュームや別のホストパスにファイルが現れた場合は、他のPlex設定を変更するのではなく、停止してマウントを修正してください。
クリーンアップ、再起動時の動作、ディスク満杯時の境界を確認する
強制トランスコードを、測定可能な一時データが作成されるまで十分な時間実行してください。その後、再生を停止し、スクラッチディレクトリが想定どおりクリーンアップされることを確認します。Plexを再起動して同じテストを繰り返し、コンテナのライフサイクルイベント後もマウントが存在し、書き込み可能であることを確認してください。
家庭内で同時ストリーミングを行うことが多い場合は、代表的なトランスコードを2本実行しながら空き容量を監視してください。成功条件は起動が速くなることだけではありません。一時パスが実際の負荷によって拡大している間も、NASにはPlexのデータベース、Docker、その他のサービスのために十分な容量が残っていなければなりません。
一時ディレクトリが繰り返し満杯になる場合は、同時トランスコード数を減らすか、スクラッチ容量を増やすか、別のローカルストレージ層を選んでください。緊急対応として設定をメディアライブラリやネットワーク共有に向けないでください。代わりに容量計画を見直してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
不整合なデータベースを取得せずに Plex をバックアップする方法
コア状態にはPlexのデータベースバックアップを使用するか、アプリデータツリー全体をコピーする前にPlexを停止し、稼働中のファイルコピーを無条件に信頼するのではなく、復元可能であることをテストしてください。
