大規模なモバイルライブラリのインポート中にImmichが検索インデックス作成をスケジュールする方法

エヴァ・ウォン

IceWhale author

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

How Immich Schedules Search Indexing During Large Mobile-Library Imports - Zima Store Online

大規模なモバイルライブラリのインポート中、Immichは検索関連のすべてのバックグラウンドジョブが完了するよりも速くアセットを受け入れられるため、検索結果の反映がアップロード完了に遅れることがあります。

この遅延は、必要なジョブが待機中、実行中、または共有リソースを奪い合っている場合にのみスケジューリング上の問題となります。自動的に検索の失敗を意味するわけではありません。実用的なモデルはパイプラインです。新しいアセットが作業を生み、キューが急増分を吸収し、ワーカーがキューを処理し、後続の検索が依存する結果をデータベースが受け取ります。

大規模なインポートでは異なるジョブが一斉に発生する

モバイルからの移行は、単にデータをコピーするだけではありません。受け入れられた各アセットは、サムネイル、メタデータ、動画処理、スマート検索、顔認識、その他有効化された機能の後続処理を発生させることがあります。これらのジョブはコストや依存関係が異なるため、1回のインポートで処理速度の異なる複数の滞留が生じることがあります。

逐次ジョブを求める声は、リソースに制約のあるホストでユーザーがこの挙動に気づく理由を示しています。運用担当者は、負荷の高い処理を重複させず、一度に1つずつ実行したい場合があります。ただし、この要望はリソース競合の証拠であって、すべてのサーバーで逐次実行が最適だという証明ではありません。

保留中の総数を1つのワークロードとして扱うのではなく、各キューについて到着数、完了数、失敗数を測定してください。大量のサムネイル処理の滞留は、動画トランスコードの滞留とは異なる形で、依存する他の処理を遅らせる可能性があります。また、着実に減少しているキューと、同じ項目を何度も再試行しているキューでは意味が異なります。

キューの優先度は、グローバルなリソース制御と同じではない

システムは特定の処理に優先順位を付けたり、一時停止したりできますが、それでも別の種類のジョブが動作している場合があります。そのため、あるインポートツールが1種類のバックグラウンド処理を減らしたとしても、CPUがアイドル状態になること、ディスクが静かになること、検索結果が直ちに反映されることが保証されるわけではありません。スケジューリングポリシーと総リソース消費量は関連していますが、同一ではありません。

immich-goのリリースでは、競合を減らすため、アップロード中にバックグラウンドジョブを一時停止する機能が導入されました。この挙動はそのインポーターとバージョンに固有のものです。したがって、すべてのImmichモバイルインポートが自動的に同じ処理を一時停止すると一般化すべきではありません。

実際の判断基準は、進行状況を観測できるかどうかです。アップロードが速く続いている一方で、検索関連のキューが意図的に一時停止されているなら、新しいアセットが検索可能になるのが遅れるのは自然です。キューが有効なのに完了数がほぼゼロのままなら、問題はスケジューリングポリシーではなく、ワーカー、リソース、または特定アセットの処理失敗にある可能性があります。

-15% OFF

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

Single board computer zimaboard2

同時実行数が増えても、応答性が悪化することがある

共有依存先が飽和するまでは、ワーカーの同時実行数を増やすことで、1分あたりの完了ジョブ数を増やせます。しかし、その限界を超えると、並列性を高めてもデータベースの待機、ストレージの遅延、メモリの圧迫、コンテキストスイッチが増える可能性があります。その結果、バックグラウンド処理の平均的な完了速度は上がっても、対話的なリクエストのテールレイテンシーが長くなることがあります。

停止したジョブキューに関する実践者の報告では、大規模なライブラリで同時実行数を減らすと、確認できる進行状況が改善しました。これは特定のデプロイ環境での観測結果ですが、同時実行数をサーバー性能の固定的な指標とみなすのではなく、ワークロードの変数として検証すべき理由を示しています。

対話操作の基準として、すでにインデックス化されたアルバムに対する既知の検索を使ってください。その検索が高速なままで新しい写真の対象範囲だけが遅れているなら、主な問題は検索結果の反映遅延です。古い検索さえ遅くなり、同時にCPU、ストレージ、またはデータベースの待機が増えているなら、スケジューリングによって対話操作に使える余力が消費されています。

増え続けるキューが自動的に障害とは限らない

ワーカーの完了速度よりも速く作業が到着すれば、バックログは増えます。意図的に過去のデータをインポートしている間、一定期間そうなるのは想定内です。障害の兆候はキューの最大長そのものではなく、完了処理の停止、エラーの繰り返し、または到着が止まった後もバックログが減少しないことの組み合わせです。

この20万枚の写真の移行のような大規模インポートに関する議論では、運用担当者がアップロード速度と後続処理を分けて考えています。コミュニティの経験は、何を測定すべきかを見極めるうえで役立ちますが、別のライブラリに対する普遍的な所要時間の見積もりに変えてはいけません。

関連するジョブが完了しており、同じ認証済みユーザーが既知のアセットを取得できない場合、この仕組みだけでは検索結果の欠落を説明できません。その時点では、インポートの同時実行数を調整し続けるのではなく、検索の関連性、フィルター、権限、モデルの挙動、またはアセット固有の処理を調べてください。

2つのレーンでスケジューリングをテストする

古いインデックス済みコンテンツ用の固定レーンと、少量の新規インポート用のレーンを1つずつ作成します。インポート前に、既知の古い検索の応答時間を記録してください。インポート中は、同じ検索、アップロード速度、保留中および完了したジョブ数、失敗数、CPU負荷、メモリ負荷、ストレージ遅延を一定間隔で記録します。

Immichのデータパスに関するZimaSpaceの分析を活用し、転送、処理、ストレージ、検索の各段階を区別してください。ボトルネックが対策可能なのは、実際に達成できていないサービス目標に対応する段階と、そのボトルネックが一致している場合だけです。

古い検索が家庭内で許容できる範囲の応答時間を維持し、新しい項目のキューが処理を完了し続け、到着が止まった後にバックログが減少するなら、そのスケジュールを採用できます。同じ共有リソースが対話操作とキューの進行の両方を遅らせていることが、管理されたテストで確認できた場合にのみ、バックグラウンドの同時実行数を減らすか、スケジュールを変更してください。