Immichは検索の応答性が低下するまでに、同時タスクをいくつ処理できますか？

エヴァ・ウォン

IceWhale author

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

How Many Concurrent Tasks Can Immich Handle Before Search Responsiveness Degrades?

Immichに全環境共通の安全なタスク数はありません。検索性能は、同時実行ワーカーがインタラクティブなリクエストでも必要とされるリソースを飽和させたときに低下します。

2台のサーバーで同じ数のサムネイル生成、メタデータ処理、機械学習ジョブを実行しても、検索レイテンシーは大きく異なる可能性があります。したがって実用的な上限とは、キューが処理され続ける中で、定義したインタラクティブ応答の目標を維持できる最大の混合ワークロードです。

タスク数だけではワークロードを表せない

同時実行数はワーカーの許容量にすぎず、負荷を直接測る指標ではありません。サムネイル生成、動画トランスコード、メタデータ抽出、機械学習による推論では、必要な計算量やストレージ処理量が異なります。軽いメタデータ処理ジョブ4件ならインターフェースの応答性を保てても、動画ジョブ2件では同じホストに大きな負荷がかかることがあります。

大量インポート後に機械学習でCPU使用率が高くなった事例についてのコミュニティ報告では、同時実行ジョブ数を減らした結果、負荷は下がった一方で完了までの時間は延びたと説明されています。この観察結果は、重要なトレードオフを裏付けています。低い同時実行数は、根本的な作業をなくすのではなく、バックログの処理を遅くすることでフォアグラウンドの応答性を守ります。

各キューをワークロードの種類として扱います。実行中のジョブ、処理対象のメディア種別、アクセラレーションの利用可否を記録してください。小さなJPEGを基準に算出した安全な合計値を、RAW写真や長時間の動画にそのまま適用することはできません。各スロットが表す作業量が変わるためです。

検索性能は最初の共有リソース飽和点で低下する

インタラクティブ検索はいくつもの共有レイヤーを通過します。リクエストがアプリケーションに到達し、データベースが結果を選択し、サムネイルが読み込まれ、クライアントに表示されます。バックグラウンドワーカーは複数のレイヤーで競合する可能性があります。すべてのコンテナが正常でも、最初に飽和したレイヤーが実質的な同時実行数の上限になります。

Immichのパフォーマンスに関する議論では、公称帯域幅が十分なホストでもサムネイルの読み込みが遅延した事例が説明されています。これは、リンク速度だけではボトルネックを特定できないことを示しています。遅いリクエスト中にどの待ち時間が増加するかを測定するまでは、CPUスケジューリング、データベースの読み取り、ファイルシステムのレイテンシー、クライアントへの配信が候補として残ります。

使用率は遅延と組み合わせて確認する必要があります。検索レイテンシーが安定している状態でCPU使用率が高いなら、生産的な飽和状態かもしれません。一方、CPU使用率が中程度でもディスク待ち時間が増加しているなら、ストレージキューが原因である可能性があります。メモリ圧迫が重要になるのは、オペレーティングシステムが使用可能なRAMをキャッシュに使っているからではなく、メモリ回収やスワップによって遅延が発生した場合です。

検索クエリが遅くなくても検索可能になるまで遅延することがある

新しいアセットのインデックス処理が完了していない場合、高速なクエリでも検索可能なコレクションが不完全な状態で返されることがあります。逆に、すべてのアイテムがすでにインデックス化されていても、データベースやストレージへのアクセスが競合していればクエリは遅くなります。どちらも「検索性能の低下」と呼ぶと、異なる2つの到達点が隠れてしまい、誤った同時実行数の調整につながります。

ZimaSpaceによるImmichのデータパスの解説では、アップロードの受け入れ、プレビューの準備完了、セマンティック検索による取得を、それぞれ異なる到達点として区別しています。この区別は負荷テストで不可欠です。ファイルが到着した時刻を、そのファイルの表現が検索対象になる時刻の代わりにすることはできません。

固定したインポート対象について、2つの時間を追跡します。1つは、すでにインデックス化された対照用写真に対するインタラクティブなクエリのレイテンシーです。もう1つは、新しくインポートした写真が、あらかじめ決めた検索結果に表示されるまでの時間です。前者は現在利用しているユーザー体験を守り、後者は同時実行数を下げた場合のスループット上のコストを示します。

-15% OFF

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

Single board computer zimaboard2

推測ではなく段階テストで上限を見つける

代表的なメディアのバッチを用意し、既知のアセットを返す固定検索を3つ選びます。稼働中の各キューをワーカー1つから始め、インポートを実行します。同じ観測時間内で、検索レイテンシーの中央値と遅い側の値、キューの処理速度、CPU、メモリ圧迫、ネットワークスループット、ストレージの待ち時間を記録します。

一般的なボトルネックに関する指針では、最も忙しそうなグラフを選ぶのではなく、ワークロードの変化をCPU、メモリ、ディスク、ネットワーク、依存関係の待ち時間と関連付けることを推奨しています。1回のテストで変更する同時実行制御は1つだけにしてください。同じ検索シーケンスとメディアコホートを繰り返すことで、変更した変数を特定しやすくなります。

遅い側の検索目標を満たせなくなった、サーバーがスワップを開始した、ストレージの待ち時間が高い状態で推移した、エラーが発生した、またはバックグラウンドキューの有効なスループットが向上しなくなった時点で停止します。その1つ前の段階を、コールドスタート後と、システムがウォームな状態の両方で再テストします。そのワークロードで再現可能な、より低い段階が、根拠を持って設定できる上限です。