Immichは通常、再起動後にSmart Searchの機械学習パスが失われた、モデルのウォームアップが完了していない、または検索用埋め込みを作成するジョブやストレージの読み取りを完了できない場合、検索可能だったプライベート写真を返さなくなります。
タイムラインに元の写真が表示されているなら、写真自体が失われた可能性は低く、検索レイヤーが未完成になっています。空の検索結果はまずサービスパスの問題として扱い、データベースとアップロードライブラリを保護したうえで、何かを再構築する前に、機械学習コンテナが利用できないのか、ジョブが遅延しているのか、エンドポイントが一致していないのか、永続パスの権限に問題があるのかを切り分けてください。
検索結果がない場合と写真がない場合を切り分ける
検索をテストする前に、タイムライン、アルバム、プライベートライブラリから、存在を確認できる複数のアセットを直接開きます。成功すれば、データベースがレコードを見つけ、Immichがファイルを読み取れています。失敗した場合は、ライブラリまたはストレージ全体に関わる障害なので、検索固有の変更を中止し、影響を受けたパスを保護してください。
再現可能な検索を3種類実行します。以前機能していた語、視覚的に明らかな語、そしてバックグラウンド処理が完了しているはずの最近アップロードしたアセットです。結果が空なのか、古いのか、以前の写真に限られるのかを記録します。これにより、エンドポイント全体の障害とインデックス作成の滞留を区別できます。
コミュニティのトラブルシューティングスレッドには、エンドポイントへの到達性の確認やジョブの再実行など、再起動後のSmart Searchに関するチェック項目がまとめられています。検索レイヤーの診断手順は、データベースを削除したり、すべてのアセットを再生成したりする理由ではなく、事例の証拠として利用してください。
再起動後の機械学習パスを確認する
サーバーと機械学習コンテナの状態を確認し、設定された機械学習URLを、それを呼び出すネットワーク名前空間からテストします。到達可能なエンドポイントでモデルリクエストが正常に完了すればこの分岐は問題ありません。接続拒否、名前解決の失敗、またはコンテナの異常が確認された場合は、修復すべきサービスパスが特定できます。
デプロイ済みのサービス名、ポート、環境変数の値、イメージバージョン、ネットワーク参加状況を、最後に正常だったCompose定義と比較します。不一致を修正したうえで、影響を受けたコンテナだけを再作成してください。単なる再起動では古いコンテナ環境は置き換わらないため、再作成したワークロードで実際に有効な値を確認します。
報告されたImmich v2.6.1の事例では、Smart Searchの失敗が異常な機械学習コンテナに関連付けられていました。バージョンに関する障害報告は、状態とログを確認する根拠になりますが、再起動後のすべての障害がこのリグレッションであることを示すものではありません。
モデルの準備状況、ジョブ、永続パスを確認する
既知の検索を1件送信しながら、機械学習のログを監視します。最初のリクエストではモデルの読み込みやダウンロードが行われ、一時的にメモリ使用量が増える場合があります。進行後に正常な応答が返れば問題ありません。繰り返しの排出、メモリ不足による終了、ダウンロード失敗が発生する場合は、メモリ、キャッシュの永続化、またはネットワークを修正すべき状態です。
Smart Searchのジョブ数と最近の失敗を確認しますが、ジョブを消去しないでください。エンドポイントが正常なのにジョブが失敗またはキュー待ちのままなら、小規模で管理されたバッチを再試行し、件数が減るかを確認します。1つのアセットが成功する場合は、全体の再インデックスをスケジュールする前に、ワーカーの同時実行数または失敗した依存関係を修正してください。
データベース、アップロードライブラリ、モデルキャッシュが、想定した永続パスに正しいIDでマウントされていることを確認します。関連するZimaSpaceのImmichの認識動作に関するガイドは、元の写真が欠落しているのか、アクセス範囲やインデックス作成範囲の問題なのかを区別するのに役立ちます。
原因に合った修正を適用し、2回の再起動で再テストする
確認できた原因だけを修正します。エンドポイント名を復元する、正しい環境でコンテナを再作成する、モデルキャッシュを永続化する、測定結果に基づいて同時実行数を減らす、所有権を修正する、または失敗したSmart Searchジョブを再試行します。以前のComposeファイルとデータベースのバックアップをすぐ使える状態に保ち、最初の対応として埋め込みを削除しないでください。
同じ3つのクエリ、古いアセット1つ、新しいアップロード1つを再テストします。成功には、実用的な検索結果、減少するジョブキュー、読み取り可能な元の写真、安定した機械学習の状態が必要です。通常の依存関係の順序でスタックを再起動してから再確認し、その後ホストを1回再起動して、マウントと名前解決が起動後も維持されることを確認します。
結果が減少した場合、元の写真が読めなくなった場合、またはデータベースが整合性エラーを報告した場合は、ロールバックしてください。2回の再起動後も同じ障害が再発する場合は、Immichのバージョン、有効なエンドポイント、コンテナの状態、関連ログ、ジョブ数、モデル名、マウント設定を添えてエスカレーションします。以前の検索可能なインスタンスは、復旧可能な状態で分離して保持してください。
サポートとヒント
もっと読む

同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。

Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。

データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。

