一時トランスコードファイルがシステムドライブを圧迫し続ける：停止方法

アクティブなトランスコード処理を停止し、一時セグメントの書き込み先を確認してから、クリーンアップを徹底し、パスをシステムドライブから移動します。

メディアサーバーは、ソースライブラリが大容量ストレージプールにあっても、HLSセグメント、リマックス済みストリーム、字幕焼き込み出力、未完了のセッションファイルをデフォルトのキャッシュまたはアプリケーションディレクトリに保存することがあります。これらのファイルが十分な速さで削除されない、トランスコードディレクトリのマッピングが正しくない、または再生終了後も放棄されたセッションが残ると、システムドライブがいっぱいになります。ファイルを削除したりキャッシュを移動したりする前に、実際のディレクトリとセッションを特定してください。

アクティブなトランスコードディレクトリと容量の大きいセッションを特定する

まず、管理したトランスコードを1つ開始し、どのディレクトリが増加するかを監視します。アプリケーション設定、コンテナパス、ホストのバインドマウント、ファイルシステム、空き容量、ファイル数、容量の大きいセッションサブディレクトリを記録してください。

Jellyfinでは、一時トランスコードファイル用に書き込み可能な場所を個別に指定できます。これにより、トランスコードパスが恒久的なメディアライブラリやメタデータのパスとは別であることを確認できます。関連する設定は一時トランスコードパスです。

アプリケーションに表示されるパスと、ホスト側で容量が減るドライブが異なる場合は、Dockerの実際のマウントと書き込み可能レイヤーを調べます。バインドマウントがないと、コンテナは意図したキャッシュボリュームではなく、システムが使用するコンテナファイルシステムに一時ファイルを書き込むことがあります。

緊急クリーンアップの前に生成元を停止する

アクティブな再生セッションを特定し、急速に増加しているファイルに関連するトランスコードだけを停止します。容量を確保する前に、最新のFFmpegログ、ソースタイトル、クライアント、出力ビットレート、字幕、開始時刻を保存してください。

過去には、再生終了後も古いトランスコードファイルが残り、ディスクがいっぱいになってサーバーを起動できなくなったことがあります。Jellyfinの課題には、ユーザーが視聴を停止した後も数時間にわたって動画がトランスコード一時フォルダーを占有していたケースが記録されています。

FFmpegが書き込み中のアクティブセッションのファイルは削除しないでください。セッションまたはサーバーを正常に停止し、ファイルが開かれていないことを確認してから、キャッシュ全体やアプリケーションデータベースではなく、明らかに一時出力と確認できたファイルだけを削除します。

長時間のストリーミングセッションでセグメント削除を有効にする

サーバーが再生中にダウンロード済みのHLSセグメントを削除しているか確認します。セグメント削除を行わないと、長時間の動画やライブストリームでは、生成された出力全体を保持するために十分なディスク容量が必要になることがあります。

Jellyfinでは、クライアントがダウンロードした後に古いセグメントを削除することで、トランスコード済みファイル全体をサーバーに保存する必要がなくなると説明しています。このオプションは、具体的にはストリーム全体の保存を防ぐためのものです。

テスト用クライアントで有効にし、再生、シーク、再開を監視します。保持されたセグメントが必要となる再現性のあるクライアント問題がある場合のみ無効にし、その場合は専用トランスコードボリュームの容量を増やし、セッションのクリーンアップをより厳格にしてください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

トランスコードパスを専用の高速ボリュームへ移動する

オペレーティングシステムのルート領域とは別に、専用SSD、NVMeキャッシュ、または十分な容量の一時ファイルシステムを用意します。移動先は同時書き込みに耐え、想定される最大のトランスコードセッションに十分な容量を備えている必要があります。

小容量のRAMディスクにトランスコードを配置したユーザーからは、ディレクトリが増え続けて一時デバイスが使い果たされる可能性があるため、キャッシュ制限を求める声が寄せられています。問題の境界は、基盤デバイスがRAMかSSDかに関係なく、上限のないトランスコードキャッシュです。

サーバーを停止し、サービスの所有権を正しく設定した新しいディレクトリを作成して、コンテナ内に明示的にマッピングし、アプリケーション設定をコンテナから見えるパスに更新します。トランスコードを1つ実行し、ホストのシステムドライブの使用量が増えなくなったことを確認してください。

古いセッションとクリーンアップの失敗を特定する

一時セッションディレクトリを、アクティブな再生セッションIDおよびFFmpegプロセスと照合します。一致するセッションや開いているプロセスがなく、変更日時も古いファイルは、サポートされているクリーンアップの対象候補です。

一般的なキャッシュクリーンアップタスクですべてのトランスコード関連ファイルが削除されるとは限りません。前述のJellyfinのクリーンアップ報告では、通常のキャッシュタスクで古いトランスコードファイルが削除されなかったため、実際に確認すべきなのはセッション固有のクリーンアップが完了したかどうかです。

クライアントの切断、コンテナの再起動、クラッシュ、ネットワーク障害、プロセスの強制終了が発生した時刻前後のサーバーログを確認します。毎日の削除スクリプトだけに頼るのではなく、サーバーが正常な停止イベントを受け取れない原因を修正してください。

同時トランスコードの最大使用容量を測定する

代表的なリモートトランスコードを1つ実行し、1分あたりの一時ファイル容量を測定します。字幕の焼き込み、HDRトーンマッピング、サポートされる最大出力ビットレートでも繰り返し測定し、想定する同時セッション数と保持時間を掛け合わせます。

システムドライブがいっぱいになると、メディアサーバーは再生以外にも影響を受けます。Jellyfinのサポート事例では、トランスコードによってドライブがいっぱいになるとウェブインターフェースに接続できなくなる可能性が指摘されており、システムボリュームの枯渇がアプリケーションの可用性に影響することが分かります。

オペレーティングシステム、ログ、データベース、パッケージ更新、Dockerメタデータ用の空き容量を確保します。トランスコードボリュームに障害が発生しても、サーバーの起動やメディアアプリケーションの起動を妨げないようにしてください。

クリーンアップを検証し、容量アラートを追加する

再生開始、シーク、一時停止、クライアント切断、サーバー再起動、同時セッションをテストします。アクティブなファイルが専用トランスコードパスでのみ増加し、セッション終了後に減少することを確認してください。

ZimaSpaceの家庭用メディアサーバーの構築ガイドでは、ソースストレージをアプリケーションや一時処理のワークロードから分離するための、より包括的な検証手順を紹介しています。

古いセッションが残らず、対応クライアントでセグメント削除が機能し、システムドライブに安全な空き容量が確保され、専用トランスコードボリュームまたはルートファイルシステムが容量しきい値に達する前にアラートが発生すれば、修復は完了です。