Jellyfinには、メタデータ、アートワーク、キャッシュ、インデックス、一時トランスコードの増加率がそれぞれ異なるため、信頼できる固定のオーバーヘッド割合はありません。
メディア容量が同じ2つのライブラリでも、アイテム数、アートワークの密度、プレビュー、スキャン、ユーザーの利用状況が異なれば、必要なアプリケーションデータ容量は大きく変わります。データディレクトリと一時パスは分けて測定してください。重要なのは、万能な5%ルールではなく、増加量とピーク時の挙動に基づいて容量を見積もることです。
永続的なアプリデータは別の容量プール
データベース、メタデータ、アートワーク、ログ、生成されたインデックスは、ブラウジング、スキャン、再生状態の更新中に使用されます。これらは、それらが説明する映画やエピソードとは別に測定する必要があります。
ストレージオーバーヘッドモデルでは、アプリデータ容量と大容量メディア容量を分けて考え、両者が異なる曲線で増加する理由を説明しています。
大規模なメディアアーカイブでもメタデータが少ない場合がある一方、アートワークやプレビューが豊富な小規模ライブラリのほうが、アプリケーション領域を多く消費することもあります。
機能設定によって使用容量は変わる
アートワークの密度、プレビューサムネイル、分析データ、アイテム数、プラグイン、キャッシュの動作によって、永続ストレージの使用量は増加します。一時トランスコードは別の要素で、変換処理の実行中にピーク時の作業領域が発生します。
ストレージパスの容量を見積もる際は、ストレージのレイテンシーとスループットを使って、レイテンシー、スループット、一時的な作業領域を区別してください。
永続的な増加分はアプリデータ予算に、一時的なピークはスクラッチ領域の予算に含めます。
割合によるルールが機能しない理由
ライブラリに小さなアイテムが多数含まれている場合、プレビューが有効になっている場合、または同時変換によって非常に大きな一時セグメントが作成される場合、固定比率は機能しません。一方で、生成アセットが最小限の単純なライブラリでは、必要容量を過大評価する可能性もあります。
ストレージオーバーヘッドモデルの比較からも、単一の割合より、現在の実測容量と増加率のほうが有用であることが分かります。
機能やワークロードによってデータの増加曲線が変わると、必要容量の境界も変わります。そのような変更後は再計算してください。
実測値から容量予算を作成する
現在のアプリデータ容量、月間増加量、一時トランスコードの最大ピーク、バックアップ用の予備容量を記録します。バックアップ用の予備容量はライブデータディレクトリの外部に確保し、通常の運用によって復旧用の空き容量が消費されないようにしてください。
ストレージオーバーヘッドモデルのストレージ予算パターンを使い、スキャン、分析設定の変更、大規模なライブラリ拡張の後に更新してください。
実測した永続的な増加分と一時的なピークの両方が、設定した空き容量マージン内に収まるまで容量を追加してください。
テック&AIハブ
もっと読む

ホームサーバーにサービスを追加すると、Home Assistantのアーキテクチャはなぜ変化するのか?
サービスを追加して共有状態、キュー、デバイス、更新サイクル、または障害ドメインが増えると、単にコンテナが増えるだけでなく、Home Assistantのアーキテクチャが変わります。

キャッシュを容量と取り違えずにHome Assistantのパフォーマンスを測定する方法
ウォーム状態での結果は、容量ではなく再利用を示します。コールドスタート、ウォーム時の定常状態、繰り返し負荷、テールレイテンシ、そして最初に飽和するリソースを測定してください。

Home Assistantで家全体を制御するには、どれくらいの自動化同時実行数が必要ですか?
家全体の自動化の多くは、重複実行数に上限を設けるだけで十分です。実行時間×トリガー発生率で同時実行数を見積もり、その後、下流システムが安全に処理できる容量を上限にします。

