Jellyfinはメディアファイル以外にどれくらいストレージ容量を消費する?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Jellyfinには、メタデータ、アートワーク、キャッシュ、インデックス、一時トランスコードの増加率がそれぞれ異なるため、信頼できる固定のオーバーヘッド割合はありません。

メディア容量が同じ2つのライブラリでも、アイテム数、アートワークの密度、プレビュー、スキャン、ユーザーの利用状況が異なれば、必要なアプリケーションデータ容量は大きく変わります。データディレクトリと一時パスは分けて測定してください。重要なのは、万能な5%ルールではなく、増加量とピーク時の挙動に基づいて容量を見積もることです。

永続的なアプリデータは別の容量プール

データベース、メタデータ、アートワーク、ログ、生成されたインデックスは、ブラウジング、スキャン、再生状態の更新中に使用されます。これらは、それらが説明する映画やエピソードとは別に測定する必要があります。

ストレージオーバーヘッドモデルでは、アプリデータ容量と大容量メディア容量を分けて考え、両者が異なる曲線で増加する理由を説明しています。

大規模なメディアアーカイブでもメタデータが少ない場合がある一方、アートワークやプレビューが豊富な小規模ライブラリのほうが、アプリケーション領域を多く消費することもあります。

機能設定によって使用容量は変わる

アートワークの密度、プレビューサムネイル、分析データ、アイテム数、プラグイン、キャッシュの動作によって、永続ストレージの使用量は増加します。一時トランスコードは別の要素で、変換処理の実行中にピーク時の作業領域が発生します。

ストレージパスの容量を見積もる際は、ストレージのレイテンシーとスループットを使って、レイテンシー、スループット、一時的な作業領域を区別してください。

永続的な増加分はアプリデータ予算に、一時的なピークはスクラッチ領域の予算に含めます。

割合によるルールが機能しない理由

ライブラリに小さなアイテムが多数含まれている場合、プレビューが有効になっている場合、または同時変換によって非常に大きな一時セグメントが作成される場合、固定比率は機能しません。一方で、生成アセットが最小限の単純なライブラリでは、必要容量を過大評価する可能性もあります。

ストレージオーバーヘッドモデルの比較からも、単一の割合より、現在の実測容量と増加率のほうが有用であることが分かります。

機能やワークロードによってデータの増加曲線が変わると、必要容量の境界も変わります。そのような変更後は再計算してください。

実測値から容量予算を作成する

現在のアプリデータ容量、月間増加量、一時トランスコードの最大ピーク、バックアップ用の予備容量を記録します。バックアップ用の予備容量はライブデータディレクトリの外部に確保し、通常の運用によって復旧用の空き容量が消費されないようにしてください。

ストレージオーバーヘッドモデルのストレージ予算パターンを使い、スキャン、分析設定の変更、大規模なライブラリ拡張の後に更新してください。

実測した永続的な増加分と一時的なピークの両方が、設定した空き容量マージン内に収まるまで容量を追加してください。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.