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

秘密ブローカーは、プロンプトに認証情報を露出させずにAIエージェントへどのように認証情報を渡すのか?
シークレットレスなホームAIエージェントアーキテクチャを通じて、ワークロードID、ポリシー、トークン発行、リクエストインジェクション、編集、期限切れ、失効を追跡します。

ツールサンドボックスはAIエージェントの副作用をどのように封じ込めるのか?
隔離、機能ゲート、使い捨て状態、送信制御、クォータ、監査ログによって、アクションの安全性を証明することなくAIエージェントの副作用を制限する方法をご覧ください。

制約付きデコーディングはどのようにスキーマ準拠のJSONを生成するのか?
スキーマのコンパイル、トークンマスキング、パーサーの状態、サポートされるサブセット、レイテンシ、切り詰め、そして構造的な有効性が正しい値を保証しない理由を理解する。

