Jellyfinはバックグラウンドジョブ用にどのくらいの空き容量を確保すべきですか？
Jellyfinでは、メタデータの増加、生成アセット、トランスコード用の一時領域、ログ、メンテナンス作業が通常発生する最大規模の組み合わせに対して、十分な空き容量を確保しておく必要があります。
シンプルなライブラリとTrickplayを多用するライブラリではアプリケーションのストレージ使用量が大きく異なるため、固定の割合を基準にするのは信頼できません。永続的に増加するデータと一時的なピークを分け、実際にデータが保存されるパスごとに両方を測定してください。メディアボリュームに空きがあっても、設定ファイルやトランスコード用ストレージが別の満杯のファイルシステムにある場合は役に立ちません。
まずアプリデータの永続的な増加量を測定する
データベース、メタデータ、アートワーク、プラグイン、生成アセットは、ライブラリや有効化した機能の拡張に伴って増加します。その推移は、ソースメディアの容量とは別に測定する必要があります。
生成アセットによって作業用データセットが大幅に増える場合があります。あるJellyfin運用者は、ライブラリ更新時に追加のストレージと処理能力を消費するため、Trickplayとチャプター画像を使用していません。
スキャンが落ち着いた後の設定ディレクトリの容量を記録し、代表的な1か月の運用後、または大規模なインポート後に再度測定してください。メディアのテラバイト数から推測するのではなく、実測した増加率を使用します。
トランスコード用の一時領域を一時的なピークとして測定する
アクティブな変換では、セッション終了時に削除される作業ファイルが作成されます。最悪のケースは、最大のソースファイル、同時に実行するトランスコード数、設定された一時パスによって決まります。
トランスコード用の一時領域をローカルの高速ストレージに置くことで、頻繁に書き換えられる一時データと永続的なライブラリの状態を分離できます。
想定される中で最も負荷の高い同時トランスコードを実行し、一時領域の使用量のピークを記録してください。その容量は、長期的なアプリデータ用の予算とは別に確保します。
スケジュールされたジョブは短時間の急増を引き起こすことがある
Trickplay、画像抽出、スキャン、プラグインによる分析は、CPUとストレージを同時に消費する可能性があります。複数のタスクが同じ時間帯に開始されると、通常のアイドル時よりも一時的な使用量が大幅に増えることがあります。
バックグラウンド処理はスケジュールされたJellyfinタスクとして確認できるため、空き容量のテストには、実際にライブラリデータを生成または更新するジョブを含めてください。
負荷の高いタスクを時間差で実行し、スケジュールを一巡するまで空き容量を観察してください。家庭用メディアサーバーの役割マップを使うと、一時データがほぼ満杯のシステムボリュームを気付かないうちに共有するのを防げます。
アラートはゼロではなく、障害発生点より前に設定する
ファイルシステムが100%に達するまで待つと、データベースへの書き込み、パッケージの更新、ログ、復旧操作に使える容量がほとんど残りません。アラートは、まだ安全にクリーンアップや移動を行える段階で発生するように設定してください。
上限のないコンテナログは、アプリケーションのメディアとは別にホストのストレージを消費する可能性があります。
実測した最大の一時的ピークに通常の増加分を加えた値を上回るように、空き容量の下限を設定してください。新しい生成メディア機能を有効にした場合や、トランスコードディレクトリを変更した場合は、再計算します。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。
誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。
Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。
