ライブラリの変更後に Immich のバックグラウンド処理が急増するのはなぜですか？

ライブラリの変更後にImmichのバックグラウンド処理が急増することがあります。これは、1つのファイルシステムイベントやライブラリイベントが、スキャン、メタデータ処理、派生ファイル生成、インデックス作成のジョブへと連鎖的に分岐する場合があるためです。

重要なのは、予想される再処理の一時的な波と、対応する変更がないままアセットを繰り返し再処理する状態を区別することです。フォルダーの移動、外部ライブラリの再スキャン、新たに検出されたファイル、バージョン固有の挙動はいずれも似たCPU使用率やキューのグラフを生じさせる可能性があるため、ライブラリイベントを、それによって作成された正確なジョブと結び付ける必要があります。

ライブラリスキャンは検出段階であり、ワークロード全体ではない

スキャンではまず、Immichがディスク上で認識できる内容と、ライブラリについて既に把握している情報を照合します。その後、新規または変更されたアセットが下流の出力を古い状態または未生成の状態にすることがあり、スキャン自体が完了したように見えた後も追加の処理が発生します。

重複するライブラリスキャンに関する実践者の報告では、スキャンキューが完了した後も、サムネイル、顔認識などのキューが大量に残っていました。ここで重要な仕組みは処理の分岐です。短い検出フェーズが、はるかに長い処理の残りを作り出すことがあります。

キューは依存関係の順序に沿って読み取ってください。ライブラリキューがゼロになった後も派生処理のキューが進行しているなら、サーバーは単に、完了したスキャンによって生成されたジョブを処理しているだけかもしれません。この期間全体を「繰り返しスキャン」と呼ぶと、実際にリソースを消費している段階が分からなくなります。

パスの変更は新しいアセットの処理に見えることがある

外部ライブラリは、ファイルシステム上の識別情報やパスの変更の影響を特に受けやすいです。ファイルを整理し直すと、アプリケーションは新しい場所と保存済みのアセット状態を照合し直す必要が生じる場合があります。バージョンやライブラリの種類によっては、実際に新しく追加された写真の数を上回る処理が発生することもあります。

2026年の移動した外部ファイルに関するディスカッションでは、整理後のパスが新しいアセットとして扱われ、サムネイルの再生成、ML解析、動画処理が再び実行された事例が報告されています。これは既知の制限に関する報告であり、すべてのフォルダー移動が同じように動作することを保証するものではありません。

これが、同じ枚数の新しい写真を追加する場合よりも、ライブラリの整理に大きなコストがかかることがある理由です。ただし、ファイルのパスと内容の両方が変わっていないにもかかわらず、完全な再生成が繰り返されるなら、別の状態が原因である可能性が高く、通常のバックグラウンド動作として受け入れず調査すべきです。

処理が完了していても下流のキューが増えることがある

待機中の件数は、必ずしも単調に減少するとは限りません。あるジョブが完了すると、別のジョブの対象になったり、後続段階にさらにタスクが追加されたりすることがあります。そのため、大規模な照合中には、サーバーが処理を進めながら、下流のキューも同時に増加することがあります。

サムネイルの滞留に関するディスカッションでは、ほかの処理が完了するにつれて新しいサムネイルジョブが現れる可能性が指摘されています。また、過去のバグや誤設定されたインポートパスが異常なループを生む可能性も示されています。したがって、キューの増加はバージョンやパスの状況を踏まえて解釈する必要があります。

待機件数だけでなく、完了した処理のカウンターと最近の出力を抜き打ちで確認してください。サムネイルが生成され、完了数が増え、最終的に新規到着数を上回るようになるなら、元のライブラリスキャンが終了した後にピークを迎えていても、キューは消化されています。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

対応する変更がない場合、その急増は異常である

予想されるバックグラウンド負荷は、新しいアセット、メタデータの更新、パスの変更、モデルの変更、明示的な再生成操作など、特定のイベントに起因しているはずです。同じ古いアセットが、設定やコンテンツの変更なしに繰り返しスケジュールされているなら、その説明は成り立ちにくくなります。

1回のスキャンが他のライブラリにも影響したという最近の報告では、複数の外部ライブラリで処理が再生成されたように見える事例が示されています。このような報告は、自分のログと比較するためのバージョン限定の証拠として扱い、Immichの標準的な動作とみなさないでください。

関連するキューが空になった後もホストが長時間高負荷のままなら、この仕組みでは説明できません。その場合は、データベースのメンテナンス、バックアップ、別のコンテナ、ファイルシステムのアクティビティ、処理が停止したプロセスなどを確認してください。ライブラリの変更を、関係のない継続的な負荷の万能な説明にしてはいけません。

変更内容を前後のジョブマップと相関させる

管理されたライブラリ変更を行う前に、アセット数、主要なジョブの待機中および実行中の件数、CPU使用率、ストレージのレイテンシ、最後に完了したスキャンの時刻を記録してください。既知の少数のアセットを追加または移動し、同じ観察をもう一度行って、どのキューがどの程度増加し、どれほどの速さで消化されるかを正確に記録します。

Immichのデータパスに関するZimaSpaceの解説を使い、すべてのバックグラウンドアクティビティを1つのカテゴリとして扱うのではなく、各スパイクを検出、処理、データベース、ストレージのいずれかに割り当ててください。

生成された処理量が管理された変更に比例し、出力が生成され、失敗が一定範囲に収まり、キューが基準値に戻っていくなら、その急増は許容できます。変更していないアセットが繰り返し再生成される、編集したライブラリを超えて影響が及ぶ、または同じジョブが進展なく失敗し続ける場合は、詳しく調査してください。