Jellyfinのアップデート動作：スキーマとキャッシュの変更が起動に与える影響

Jellyfinは、アップデート後にデータベースの移行とキャッシュのコールド状態による一度限りの処理が通常のリクエスト再開前に加わるため、起動が大幅に遅くなることがあります。

通常なら数秒でJellyfinを開けるホームサーバーでも、プロセスが正常に動作しているのに、大規模なバージョン変更後は停止したように見えることがあります。重要なのは、スキーマ変換、インデックスのメンテナンス、キャッシュの再構築といった有限のアップグレード処理と、マウント不良、空き容量不足、定常状態に到達できない中断された移行など、繰り返し発生する障害を区別することです。

スキーマ変更によって、起動はデータ変換になる

スキーマ変更は、単に新しい実行ファイルで古いデータベースを読み取るだけではありません。アプリケーションは、新しい構造が存在することを後続のコードが安全に前提とできるようになる前に、テーブルの作成、リレーションの書き換え、レコードの重複排除、データの新しい形式への移行などを行う必要があります。この処理量は永続化された状態の量と構造に比例するため、ライブラリが大きかったり複雑だったりすると、同じソフトウェアアップデートでも時間がかかることがあります。

Jellyfin 10.11は、その仕組みを直接示す例です。ライブラリ変換では、従来のライブラリデータベースから新しいEF Coreベースの構造へデータが移行され、大規模なインスタンスでは初回の移行に数時間かかる可能性があるとプロジェクトが警告しています。したがって、この長時間実行される移行は、通常のサービス初期化ではなく、起動時に永続的な変換が行われる例として役立ちます。

重要なのは、移行時間には限りがあり、進行が前に進むはずだという点です。通常のUIが利用できないからといってサービスを何度も再起動すると、起動のたびにロックの再取得、状態の再確認、高コストな処理の再開が必要になり、逆効果になることがあります。バージョン固有の移行は、ログまたは起動ステータスに完了、あるいは安定して再現するエラーが示されるまでは、メンテナンス処理として扱ってください。

キャッシュの変更によって、最初の正常な起動は異なって見える

永続的なスキーマが有効になった後でも、メモリ上のデータベースページ、アートワーク、ディレクトリエントリなど、再利用可能なオブジェクトがコールド状態であるため、最初のリクエストは遅くなることがあります。再起動するとプロセスメモリは破棄され、アップデートによってキーや形式が変更されたディスクキャッシュが無効になることもあります。そのため、最初のブラウジングでは、後続のリクエストなら回避できる読み取りや解析のコストが発生します。

このコールド状態とウォーム状態の違いは、コールド／ウォームリクエストモデルから確認できます。メタデータや準備済みオブジェクトが再利用可能な状態に保たれると、基盤となるCPU、ネットワーク、メディアファイルが変わっていなくても、繰り返しのリクエストは速くなることがあります。2回目のライブラリ表示が速くなったからといって、アップデートによってハードウェアの処理能力が増えたという意味ではありません。これは再利用が起きた証拠です。

同じ「ウォーム状態」のはずのリクエストが毎回遅い場合は、障害の可能性があります。キャッシュの継続的な追い出し、コンテナ起動のたびに再作成されるパス、メモリ不足、想定されるワーキングセットに収まらなくなったデータベースなどによって、システムがウォーム状態に到達できないことがあります。起動処理が実際に落ち着いた後で、同一のリクエストを比較してください。

ストレージのレイテンシーは、移行とウォームアップのコストを増幅する

スキーマ移行とキャッシュの構築では、多数の小さな読み取りと書き込みが発生するため、映画のストリーミングで重要なシーケンシャルスループットよりも、レイテンシーとキューイングの影響が大きくなります。ハードドライブは高ビットレートの動画を問題なく配信できても、起動時に発生する何千ものデータベースページ、メタデータファイル、ディレクトリ検索、同期書き込みへの対応では、SSDより大幅に時間がかかることがあります。

LinuxのファイルI/Oも、通常のバッファ付き処理ではページキャッシュを経由します。読み取りによってメモリページが埋められ、書き込みによって、後で永続化する必要のあるダーティページが作成されます。このページキャッシュの読み取り／書き込み経路は、低速なストレージ上のコールド状態のデータベースで、ワーキングセットが再利用された後の同じデータベースよりも物理I/Oが大幅に多く見える理由を説明するのに役立ちます。

ただし、原因はストレージだけとは限らないため、SSDはアップグレード失敗に対する万能な解決策ではありません。破損したデータベース、見つからないマウント、権限エラー、互換性のないプラグインによって起動が停止している場合、レイテンシーを下げても、誤った処理がより速く失敗するだけです。ストレージのメトリクスは、有効な処理に費やされた時間を説明するために使い、エラーの分類の代わりにはしないでください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

RAMを増やすと再読み取りを減らせるが、移行処理そのものはなくならない

メモリ容量によって、アクティブなデータベースとファイルシステムのワーキングセットを、アクセス後もどれだけホットな状態で保持できるかが変わります。必要なページが十分に収まる場合、後続のクエリではデバイスからの読み取りを大幅に回避できます。メモリに余裕がない場合は、メモリ回収によってページが追い出され、サーバーが再度取得しなければならなくなります。これはスキーマ移行を実行するという論理的な要件よりも、起動の後半と最初のユーザー操作に大きく影響します。

10.11のバックエンドでは、より積極的なインメモリデータベースキャッシュが明示的に採用され、JellyfinのRAM使用量が大幅に増え、ライブラリデータベースのサイズに近づく可能性があると説明されています。このデータベースキャッシュの変更により、アップデート後のサーバーでメモリ使用量が増えながら定常状態のアクセスが速くなるという、一見矛盾する2つの現象が同時に起こり得ます。

ただし、メモリ圧迫には注意が必要です。キャッシュの追加が役立つのは、ホストがJellyfin、カーネル、周辺サービスを圧迫せずに必要なページを保持できる間だけです。システムで激しいスワップが発生していたり、コンテナのメモリ制限によって回収が繰り返されたりすると、ウォームアップが安定しないことがあります。RAM使用量だけで判断せず、常駐メモリ、メモリ回収またはスワップの状況、繰り返しリクエストのレイテンシーをまとめて記録してください。

起動テストで、想定内のアップグレード処理と障害を切り分ける

有効なテストでは、デプロイ定義とストレージパスを一定に保ち、正確なアップデート前のバージョンを記録したうえで、3つの段階を分けて計測します。具体的には、プロセス起動から移行処理の開始まで、移行完了から利用可能なインターフェースまで、初回利用から繰り返しリクエストがウォーム状態になるまでです。これにより、「起動時間」という曖昧な1つの数値を、データを削除したり複数の変数を同時に変更したりせず比較できる段階に分解できます。

コンテナの再作成では、Jellyfinのイメージだけを意図的に更新した場合でも、マウント、デバイス、依存関係、起動順序が変わることがあります。そのため、より広いサービススタックのモデルが役立ちます。このサービス依存関係の境界は、コンテナが正常であっても、Jellyfinの初期化時にすべての永続パスや上流サービスの準備が完了していたとは限らない理由を示しています。

移行の進行が単調に進み、同じ永続状態がクリーンな再起動を1回行った後にも再び開け、繰り返しリクエストが想定されるウォーム状態の基準値付近に落ち着くなら、アップデートは成功と判断できます。同じ移行が無限に再起動される、空き容量が予想外に減る、データベースで整合性エラーが報告される、サービスが新規サーバーとして起動する、といった場合は停止してログを保存してください。これらは通常のキャッシュウォームアップではなく、障害の兆候です。