アップグレード後にImmichが既存のデータを再処理するのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Immich Reprocess Existing Data After an Upgrade?

Immichでは、アップグレードによって現在の出力を定義するコード、モデル、メタデータ、派生データのルールが変更されると、既存のアセットが再処理されることがあります。

元の写真自体は変わっていなくても、サムネイル、埋め込み、顔認識結果、プレビュー、データベースレコードが新しいリリースの要件を満たさなくなる場合があります。以下では、どの出力が無効になり、どのキューがそれを再生成し、処理が一度で完了するのか、それとも異常に繰り返されるのかを限定的に説明します。

アップグレードによって、現行の出力とみなされる条件が変わることがある

生成データの有効性は、それを生成したコード、モデル、設定、スキーマとの関係で決まります。これらの前提が変わると、既存のサムネイル、埋め込み、顔認識結果、メタデータレコードが現行のものとみなされなくなる可能性があります。入力であるアセットは残ったままでも、作り直しが必要なのは派生データだけということがあります。

ZimaSpaceのImmichバックアップ記事では、再生成できる派生データと、不可欠なオリジナルおよびデータベース状態を区別しています。この区別から、元のファイルが複製されたわけではなく、変更されていないメディアを基にアプリケーションが派生状態を再構築しているだけでも、アップグレード後の処理量が大きくなる理由が分かります。

アップグレード直後にどのキューが増え、どのディレクトリやデータベースのサイズが変化するかを記録してください。サムネイルキュー、機械学習キュー、データベースのマイグレーションは、それぞれ異なる仕組みです。すべてを「再インデックス」と呼ぶと、所要時間やリソース負荷を見積もるために必要な証拠が失われます。

依存関係やモデルの変更によって、以前の処理が無効になることがある

Immichは、アプリケーションコード、データベースの動作、キューの調整、機械学習モデル、メディアの派生データで構成されています。アップグレードによって、これらのコンポーネント間のインターフェースや保存形式に関する前提が変わることがあります。マイグレーションによってレコードがすぐに更新されても、バックグラウンドワーカーが影響を受けた各アセットの高負荷な出力を後から再生成する場合があります。

Immich v3の準備に関するコミュニティの議論では、PostgreSQL、Redis、ベクトル拡張、アプリケーションのバージョンについて不確実性が取り上げられています。この議論は特定のアップグレード手順を証明するものではありませんが、依存関係の互換性が無関係な保守作業ではなく、状態遷移の一部であることを示しています。

アップグレード前の各コンポーネントのバージョンと、アップグレード後のキューのスナップショットを保存してください。1種類の出力だけがスケジュールされ、一度で完了するなら、その挙動は限定的な再生成と一致します。コンポーネント間でスキーマや拡張機能の認識が一致していない場合は、有用な再処理が始まる前から失敗が繰り返されることがあります。

再処理によって、互換性への対応がリソース負荷に変わる

規模の大きなライブラリでは、1つのルール変更が数千件のジョブにつながることがあります。サムネイル生成やメディア分析はCPUまたはアクセラレーターを消費し、オリジナルの読み取りと派生データの書き込みはストレージ帯域を消費します。データベースの更新とキューの処理も同時に続くため、再処理が正常に進んでいても、通常のブラウジングが遅くなることがあります。

Immichのサポートスレッドでは、2台のサーバーでアップデート後に夜間のCPU使用率が高くなったことと、サムネイル生成が再び行われたことが報告されています。これは意図された動作の証明ではなく現場からの報告ですが、キューの進行状況、ログ、処理完了の繰り返しと照合すべき具体的な観察パターンを示しています。

1分あたりの完了件数、ストレージの空き容量、デバイスの遅延、メモリの逼迫状況、固定した対話的リクエストを追跡してください。正常な再処理では、有限のバックログが減少します。同時実行数を下げれば、処理時間は長くなる一方で家庭内での利用を保護できます。ワーカーを増やすと、ストレージやデータベースの競合がすでに上限を決めている場合には、かえって悪化することがあります。

Featured

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

ZimaCube2

一度きりの再生成と、繰り返し発生する障害を区別する

アップグレード前に、ジョブ数、バージョン、空き容量、既知のアセット識別子をいくつか保存してください。アップグレード後は同じ識別子を確認し、どの出力が再構築されたか、キュー数が減少しているか、再起動後や次回の定期メンテナンス時間帯に処理が再び発生するかを記録します。

サムネイル復旧に関する議論では、処理が最終的に完了すると表示されなかった画像が解決し、個別のアセットでは手動更新が役立ったと報告されています。報告内容が混在していることからも、経過時間だけでは挙動を分類できないことが分かります。有限のキューが進む場合と、同じアセットが繰り返し失敗または再投入される場合は異なります。

キューが一貫して減少し、出力が安定しているなら、一度きりの再生成と考えます。完了件数がリセットされる、同じアセットが繰り返し現れる、エラーが再発する、空き容量が急減する、有効な処理速度が得られないといった場合は、詳しく調査してください。ジョブの状態を変更する前にバックアップとログを保存してください。証拠を削除すると、ループの原因がアップグレードなのか環境なのかを特定しにくくなります。