ライブラリが増えるほどJellyfinの起動が遅くなる理由

Jellyfinの起動時間は、ライブラリが大きくなるにつれて長くなることがあります。再オープンまたは処理が必要な永続レコード、データベースページ、メタデータ、キャッシュ状態が増えるためです。

メディアコレクションが大きくなっても、すべての起動ステップが線形に拡大するわけではありません。テラバイト数よりも、アイテム数、メタデータの関連性、データベースのサイズ、保留中のメンテナンスのほうが重要な場合もよくあります。重要なのは、どの起動フェーズが増大しているかです。永続状態のオープン、マイグレーションの実行、ライブラリの検証、キャッシュのウォームアップ、ストレージや依存サービスが応答可能になるまでの待機のどれなのかを確認します。

ライブラリの増加はメディア容量だけでなく永続状態を拡大させる

Jellyfinは通常の起動時に、動画データからメディアライブラリ全体を再構築するわけではありません。しかし、カタログが大きくなると、通常はデータベースの行、プロバイダーID、人物情報、アートワークへの参照、ユーザー状態の関連付け、ファイルシステムパスなどが増えます。これらの構造によって、オープンしてクエリを実行する必要がある永続状態が大きくなるため、メディアディスク自体が十分なシーケンシャルスループットを備えていても、起動時の挙動は変化します。

カタログサイズとメディア容量の違いは、Jellyfin 10.11のマイグレーション設計からも確認できます。この設計では、メディアファイル自体からコピーするのではなく、データベース構造内でライブラリデータを移動し、重複排除しました。ライブラリデータベースの変換は、NASに保存されているテラバイトの総量よりも、レコード数やスキーマ処理のほうが起動時間に大きく影響する場合がある理由を示しています。

ただし、ライブラリの増加だけでは原因を特定できません。小規模なデータベースでも、見つからないネットワークマウントや破損したプラグインを待機すれば起動は遅くなります。一方、非常に大規模なデータベースでも、高速なローカルストレージからメンテナンスなしで開けるなら、起動時間は安定したままです。生のメディア容量とは別に、データベースとメタデータの状態を測定してください。

データベースページとインデックスはコールド時のワーキングセットを増やす

データベースが大きくなると、起動時のクエリや最初のライブラリリクエストを処理するために、より多くのページが必要になることがあります。コールド状態のプロセスには、それらのページが自身のメモリに存在しません。ホストがコールド状態なら、ファイルシステムキャッシュにも存在しない可能性があります。そのため、カタログの頻繁に使用される部分が常駐し、後続の検索で再利用できるようになるまで、サーバーはより多くの物理読み取りを実行します。

ウォームキャッシュの挙動は、この影響を確認する手がかりになります。初回アクセスではメタデータやページの取得が必要なため遅くなることがありますが、CPU、ディスク、ネットワークのハードウェアに変化がなくても、繰り返しアクセスは高速になります。したがって、コールドスタートの時間とウォーム状態で安定した時間は、同じ安定した数値の2つのサンプルではなく、別々に測定すべきものです。

アクティブなワーキングセットを常駐させ続けられない場合が問題の境界です。メモリ不足、厳しいコンテナ制限、競合するサービスによって有用なページが繰り返し追い出されると、あらゆる画面遷移がコールドスタートのようになります。この場合、ライブラリのサイズが影響するのはメモリ圧迫を通じてであり、Jellyfinが起動時に全アイテムを意図的に再スキャンしているからではありません。

大規模なアップデートではライブラリのサイズがマイグレーション時間に直結する

通常の再起動でスキーマを書き換える必要はありません。しかし、大規模リリースでは、存在する状態の量に応じてコストが変わる一度限りの変換が追加されることがあります。そのため、大規模なカタログでは、アップデート直後の起動だけが、その後の10回の起動より大幅に遅くなる場合があります。その一度のマイグレーションを恒常的な起動時間の基準として扱うと、ライブラリの増加による長期的な影響を過大評価することになります。

Jellyfinは、10.11への初回アップグレードで、ライブラリのサイズと状態によっては数時間に及ぶマイグレーションが発生する可能性を明確に警告していました。このサイズ依存のマイグレーション期間は、アップグレード時の起動と通常の起動を分けて考えるべき強い根拠です。新しい永続状態が正常に確定した後、同じサーバーが完全な変換を繰り返すはずはないからです。

境界となるのは再現性です。再起動のたびに同じ長いマイグレーションが始まるように見える場合は、ログを保存し、その遅延を通常のスケーリングとして扱う前に、サービスが意図した永続ディレクトリを再オープンしているか確認してください。一度限りの有限な処理は想定内ですが、同一のマイグレーション処理が繰り返される場合は、永続化、ロールバック、または失敗状態に問題がある可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

小さな処理が増えるほどストレージのレイテンシーが重要になる

ライブラリが大きくなると、データベースやメタデータに対する小規模な処理が増える傾向があり、アクセスレイテンシーがより目立つようになります。HDDは大規模なシーケンシャルメディア読み取りには適していますが、アプリケーション状態では、より小さく非シーケンシャルな処理が発生します。そのため、起動中にアクセスするページやファイルの数が多少増えるだけでも、低レイテンシーのローカルストレージと、より遅い機械式またはリモートのパスとの差が大きく現れることがあります。

Jellyfin独自のストレージモデルでは、JellyfinのファイルにはSSDを推奨しています。Jellyfinのファイルはランダムアクセスが多く、メディアストレージは主にシーケンシャル速度による制約を受けるためです。アプリケーション状態のストレージに関する指針は、メディアライブラリの大部分を移動しなくても、データベースとメタデータだけを低レイテンシーの階層へ移すことで、起動やブラウジングの速度が変わる理由を説明しています。

ただし、境界となるのはドライブの種類ではなく、測定されたキューイングです。別の持続的な書き込み処理と共有しているSSDでも停止することがありますし、小規模でウォーム状態のアプリケーション状態ならHDDで十分な場合もあります。容量の増加には自動的に別のストレージ技術が必要だと判断する前に、同じライブラリで起動時のI/Oレイテンシーとキュー深度を比較してください。

サーバーの性能不足と判断する前に、起動をフェーズごとに測定する

5つの時刻を記録します。プロセス起動、永続データベースのオープン、マイグレーションまたはメンテナンスの完了、利用可能なWebインターフェース、そして代表的なライブラリリクエストの初回応答です。アップグレードが保留されていない状態でクリーン再起動を行い、コールド状態とその後のウォーム状態で1回ずつテストを繰り返します。データベースサイズ、空きメモリ、ストレージレイテンシーも加えて記録し、抽象的なライブラリサイズではなく、どのリソースによって増大しているのかを特定できるようにします。

リソース飽和のフレームワークは、結果の解釈に役立ちます。CPUの実行キュー、メモリ圧迫、ストレージレイテンシー、ネットワーク待機時間は、それらが制限しているフェーズに応じて増加するはずです。ローカルのリソースがすべて健全なのに起動時間が伸びる場合は、ハードウェアを購入したりライブラリを移動したりする前に、依存サービスの準備状況とアプリケーションログを確認してください。

通常の起動が安定し、マイグレーションが一度で完了し、最初のウォーム状態のリクエストが期待される基準値に戻るなら、現在のホストを使い続けて問題ありません。同じフェーズが繰り返し測定するたびに増大し、そのリソースに継続的な飽和が見られる場合は、配置や容量を見直してください。一方、起動時に整合性エラー、マウントの欠落、新規サーバー状態が報告される場合は、データを変更する前に停止してください。