Plexは、キャッシュ、トランスコード出力、ログ、プレビュー、または中断された処理が、それを作成したリクエストの終了後も残り続けることで、想定以上の一時データを保持する場合があります。
増え続けるディレクトリがすべてリークとは限りません。再利用可能なキャッシュである場合もあれば、実行中のトランスコードに属する場合もあります。また、クリーンアップが実行されなかった、あるいは別の機能が長期間保持される派生データを保存しているために残ることもあります。削除する前にパスの種類を分類し、パフォーマンス用データと永続的なサーバー状態を混同しないようにしましょう。
キャッシュはリクエスト終了後も保持されることがある
キャッシュは、元のリクエストが終了した後も最近使用したデータを利用できるようにするためのものです。そのため、キャッシュの使用率が高いからといって、アプリケーションがすべてのバイトを直ちに必要としているとは限りません。
メモリは、通常のページキャッシュの動作により、より有効な用途にその領域が必要になるまで、再利用可能なデータを保持することがあります。
実際にメモリが逼迫したときにキャッシュが縮小するか、またキャッシュを消去した場合に変化するのがウォームアップ動作だけかを確認してください。健全で再利用可能なキャッシュを、永続的なリークとして扱わないでください。
トランスコードデータはセッションの存続期間に従うべき
一時的なトランスコードファイルは作業用データであり、正規のメディアライブラリではありません。セッション終了後も増え続ける場合は、クリーンアップ処理やコンテナのマウント先が、Plexが実際に使用しているディレクトリと一致しているか確認してください。
Plexはメタデータとサーバー状態をメディアファイルから分離しています。そのため、一時的な作業データは独自の復旧分類で管理する必要があります。
既知のトランスコードを終了し、一時ディレクトリがクリーンアップされるか確認してください。古いセッションがいつまでも残る場合は、ディスク割り当てを増やす前にマウントパスと権限を確認しましょう。
エラーが繰り返されているためにログが増え続けることがある
保持されたログは、単なる保持設定の問題ではなく、クラッシュループ、到達不能な依存関係、または大量の警告の症状である場合があります。ローテーションを速めても症状が隠れるだけで、書き込み処理自体は残ります。
制限付きのDockerログローテーションは、基となる書き込み元とメッセージパターンを把握した後にのみ、サイズの制御に役立ちます。
保持期間を変更する前に、最も速く増えているファイルと、繰り返し表示されるメッセージを特定してください。まずエラーを修正し、その後、実際のトラブルシューティングに必要な範囲でログの保持期間を設定します。明確な永続的なアプリデータの構成により、Plexの永続的な状態と、サイズを制限するか再生成できるログ、キャッシュ、一時ファイルを区別しやすくなります。
プレビューと分析データは意図的に長期間保持されることがある
生成されたアーティファクトの中には、後のブラウジングや再生を快適にするために存在し、トランスコードのセグメントと同じ意味での一時データではないものがあります。これらを削除すると、負荷の高い再生成が発生することがあります。
ストレージ計画では、バックアップ容量と変動量を、再構築可能な派生データとは分けて考える必要があります。そうしないと、破棄可能なアーティファクトまで永続的にバックアップしてしまう可能性があります。
どの生成ディレクトリが再構築可能で、どれが維持したい利用体験に必要なのかを文書化してください。本当に破棄可能なパスを長期バックアップから除外するのは、復元テストによってその分類が正しいと確認してからにしましょう。
テック&AIハブ
もっと読む

バックアップ頻度はPlexの復旧時点の品質にどのような影響を与えますか?
任意のコピー数ではなく、復旧ポイントの要件、障害の発見が遅れるリスク、取得時の整合性、復元テストを基準にPlexのバックアップ頻度を選びましょう。

安全なPlexアップグレードの境界とは何か、そしてなぜ重要なのか?
ランタイム、状態、アクセラレーション、ロールバックデータ、エンドツーエンド検証を明確な変更境界に分離し、Plexのアップグレードをいつでも元に戻せるようにします。

Plexはデバイス間の変更をどのように検出し、同期するのか?
Plexデバイスの整合性を理解するには、信頼できるサーバー状態、クライアントキャッシュ、アカウントのアイデンティティ、そして各デバイスが使用するネットワーク経路を分けて考えます。

