Jellyfinが予想以上に多くの一時データを保持する原因とは？

Jellyfinは、トランスコード、キャッシュ、生成されたメディア成果物、クリーンアップジョブがそれぞれ異なるライフサイクルに従うため、予想以上に多くの一時データを保持することがあります。

キャッシュや一時ディレクトリが増大していても、それだけで自動的にメモリリークなどの障害を意味するわけではありません。アクティブなセッションに属するファイルもあれば、再利用可能な派生データもあります。また、一定の経過時間やスケジュールの条件を待っているものや、クリーンアップ前にジョブが終了したため残っているものもあります。まず生成元とライフサイクルを診断してください。原因不明のディレクトリを削除すると、証拠を隠したり、原因を解決しないまま高コストな再生成を強制したりする可能性があります。

根本原因は単なる大きなキャッシュではなく、ライフサイクルの不一致

一時データが疑わしくなるのは、観測された保持期間が、それを作成したイベントと一致しなくなった場合です。トランスコードの作業データは再生状況に追従するはずですが、再利用可能なサムネイルやトリックプレイデータは意図的に1回のセッションを超えて保持されることがあります。また、クリーンアップによって管理されるファイルは、タイマーやしきい値に達するまで残る場合があります。すべてのパスが「一時的」に見えても、これらは異なる契約に基づいています。

リソース使用量が大きい場合のJellyfinのトラブルシューティングでは、アクティブなトランスコードとその他のバックグラウンド処理を区別します。そのため、残存ファイルを孤立ファイルだと決めつける前に、アクティブなトランスコードを確認する必要があります。所有者と稼働中の利用元がまだ存在するファイルは、サイズが大きいというだけで古いファイルになるわけではありません。

障害となるのは、原因を説明できない増大です。アクティブな生成元がそのデータを必要としておらず、保持を正当化する再利用ポリシーもなく、いつ消えるはずかを示すクリーンアップルールもない状態です。この3つの説明がすべて成り立たない場合、保持された一時データは派生メディア処理に伴う通常のコストではなく、運用上の欠陥になります。

保持された一時データの4つの原因

削除する前に、保持されたファイルを生成元で分類してください。役立つ分類は、アクティブなセッションデータ、再利用可能な派生成果物、ポリシーに基づくクリーンアップを待つファイル、そして中断された処理によって残された孤立中間ファイルです。各カテゴリには、それぞれ異なる安全な削除タイミングがあります。

経過時間に基づくクリーンアップシステムは、「現在使われていない」ことと「削除可能である」ことが同じではない理由を示しています。保持期間は、タイムスタンプ、ルール、スケジュールされた一括処理に関連付けられることがあります。そのため、経過時間に基づくクリーンアップルールは、ライフサイクルポリシーと即時のセッション状態を分けて考えるための有用なモデルになります。

以下の4つの特徴を使って、増大が予想されたものか、遅延しているものか、孤立したものかを判断してください。ディレクトリに破棄可能な作業ファイルが含まれているのか、再生成すれば同じ容量を再び消費する再利用可能な成果物が含まれているのかを把握する前に、全体へ一律のサイズしきい値を適用しないでください。

原因1：アクティブなトランスコードが作業データを保持している

• 仕組み：再生中、または終了直後のセッションが一時セグメントを書き込み、トランスコードパイプラインが解放するまで有用な状態が続きます。
• 兆候：ファイルの更新日時とディレクトリの増大が、アクティブなトランスコードセッションや直近のシーク操作に連動します。
• IF–THEN：すべてのトランスコードが終了した後に作業データの変化が止まり、解放されるなら、孤立データではなくセッションに紐づくデータとして扱います。

原因2：再利用可能な派生成果物が意図的に永続化されている

• 仕組み：サムネイル、トリックプレイ画像、メタデータ、その他の生成済み表現は、将来のクライアントが再利用できるよう保持されます。
• 兆候：ファイルがセッション間で安定して残り、ブラウジングやシーク中に再び読み込まれます。そのため、トリックプレイとメタデータのファイルは、1セッション限りの一時データというより、キャッシュ可能な派生状態として動作することがあります。
• IF–THEN：ファイルを削除しても予測可能な再生成が発生するだけで、長期的な使用容量が減らないなら、繰り返し削除するのではなく、生成と保持を管理します。

原因3：クリーンアップが経過時間またはスケジュールのトリガーに達していない

• 仕組み：生成元の処理は終了していても、削除を担当する別のクリーンアッププロセスが後から実行されます。
• 兆候：再生や分析の直後に消えるのではなく、一定の時刻または経過時間のしきい値に達した時点で、古いファイルがまとまって消えます。
• IF–THEN：保持期間が文書化された、または観測されたクリーンアップ期間と一致しているなら、ディスクの空き容量を確保する必要がある場合にのみ、期間を短くするようポリシーを調整します。

原因4：中断された処理が孤立した中間ファイルを残している

• 仕組み：プロセスが一時ファイルを作成した後にクラッシュしたり、強制終了されたり、クリーンアップを実行しない終了経路を通ったりします。
• 兆候：古いファイルにアクティブな所有者がなく、再利用のパターンもなく、中断されたジョブの時刻付近にタイムスタンプが集中しています。実際の自動化の失敗例が示すように、中断後にクリーンアップが実行されないと、大きな作業ディレクトリが蓄積する可能性があります。
• IF–THEN：同じジョブがキャンセルまたは失敗するたびにファイルを残すなら、終了時のクリーンアップを修正し、その後で孤立していることを確認できたファイルだけを削除します。

異常増大と予想される保持を見分ける境界

ディレクトリのサイズだけで判断しないでください。ファイルの経過時間の分布、直近の更新状況、アクティブなJellyfinセッション、スケジュールされたジョブ、疑わしいファイルを開いたままにしているプロセスを記録します。予想される保持には所有者またはルールがあります。異常な増大にはそのどちらもないか、ルールを繰り返し超過します。

ファイルシステムの使用量も診断を誤らせることがあります。Linuxでは、削除されたファイルでもプロセスが開いたまま保持している間はブロックを消費し続けるため、表示されるパス名が消えた後も削除済みファイルがディスク容量を占有し続けることがあります。`df`とディレクトリの合計値が一致しない場合は、さらにデータを削除する前に、開いているファイルディスクリプタを調べてください。

生成元が終了し、想定されたクリーンアップ期間が過ぎ、ファイルが再利用可能な派生状態でもなく、手動で削除しても容量が増え続ける、または再び現れるなら、異常の境界を越えています。この時点でキャッシュサイズだけを変更しても、症状を扱っているにすぎません。データを生成、終了、無効化、削除するライフサイクルを修正してください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

何かをクリーンアップする前に一時データ台帳を作成する

サイズの大きな一時パスごとに、生成元、データの役割、アクティブな所有者、最も古いファイルと最も新しいファイルの更新時刻、再利用の兆候、想定されるクリーンアップのトリガー、現在のサイズ、安全に削除できる条件を簡潔な台帳に記録します。これにより、「キャッシュが巨大だ」という印象を検証可能な事実に変え、後からの増大を既知の基準値と比較できるようになります。

ZimaSpaceによる読み取りと書き込みのワークロードの違いについての説明は、現在生成されているデータと、単に再利用されているデータを区別するのに役立ちます。ファイルの所有者が不明な場合は、クリーンアップによって証拠を変える前に、Linuxのプロセス調査でどのプロセスがまだファイルを開いているかを特定できます。

台帳によって削除可能な集合が特定され、生成元がそのデータを使用していないことを確認できた場合にのみ、クリーンアップの判断を実行します。確認済みの少量のサンプルを削除し、Jellyfinの動作を確認してから、クリーンアップルールを適用してください。ディレクトリがすぐに同じ安定したサイズまで再び増えるなら、延々と削除を繰り返すスケジュールを設定するのではなく、生成元または保持ポリシーを調整します。