再起動後のImmichの起動時間を短縮する方法

エヴァ・ウォン

IceWhale author

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

How to Reduce Immich Startup Time After Reboot - Zima Store Online

Immichがホームサーバーの再起動後にしか使える状態になるまで遅い場合は、アプリケーション自体を「高速化」しようとする前に、どの依存コンポーネントの準備が最後になるのかを測定してください。

再起動時には、ストレージのマウント、PostgreSQL、ネットワークパス、DNS、その他のサービスが、通常のImmich再起動時とは異なる順序で準備されることがあります。重要なのはDockerがコンテナの起動を報告した時刻ではなく、ホストの起動から、データベースが実際のリクエストを受け付け、必要なストレージがマウントされ、Immichが依存関係の再試行を停止し、クライアントでタイムラインを読み込めるようになるまでの時間です。その順序を一度記録し、実際の待機や再試行ループを取り除いてください。

何かを変更する前に起動タイムラインを測定する

メンテナンス時間帯に再起動し、ホストに接続可能になった時点、Immich関連のストレージがマウントされた時点、データベースが正常になった時点、クライアントでImmichが使用可能になった時点の4つを記録します。さらに、コンテナの起動時刻、ヘルス状態、再起動回数、各サービスで最初に役立つログ行も収集してください。これにより、「起動が遅く感じる」という印象を、具体的な遅延として把握できます。

その結果を、ホストが完全に起動した後に通常どおりスタックを再起動した場合と比較します。後からImmichを再起動するとすぐに立ち上がるのに、起動時だけ遅い場合は、ボトルネックがアプリケーション外部の起動順序または準備状態の依存関係にある可能性が高いでしょう。どちらも同じように遅い場合は、データベースの処理、ストレージのレイテンシ、マイグレーション、またはCPU負荷を調べてください。

すべての層を一度に最適化しないでください。この段階のゴールは、コンテナの起動時刻に対して準備が遅れている、またはImmichに繰り返し再試行を強いている最初のコンポーネントを特定することです。

Immichの起動前にストレージが準備できているか確認する

Immichのサービスが起動する前に、すべてのバインドマウントとネットワーク経由のパスが存在し、想定したデータを含んでいることを確認してください。マウントポイントは空のローカルディレクトリとして存在していても、実際のディスクやNAS共有がまだ利用できない場合があります。その状態では、アプリケーションが誤ったファイルシステムのビューを使って起動する可能性があります。

データベースやメディアが、起動時に遅れて現れるストレージ上にある場合は、ホストレベルでサービスがそのマウントに依存するようにするか、マウントが確実に存在することを確認できるまでスタックの起動を遅らせてください。テストでは、ディレクトリ名が存在することだけでなく、実際にマウントされたファイルシステムや既知のマーカーを確認する必要があります。

ストレージの準備状態を調整したら、もう一度再起動して同じタイムスタンプを比較します。変更が成功していれば、定常時のImmich設定を変えずに、再試行や空のパスを使う動作がなくなります。ストレージがデータベースより十分早く準備できていた場合は、任意のスリープタイマーを追加せず、依存関係の順序を調べてください。

単に実行中ではなく、データベースが正常な状態になるまで待つ

特に異常終了、ストレージの遅延、初期化、リカバリの後では、PostgreSQLはコンテナが実行中になっていても、アプリケーションの処理を受け付ける準備ができていないことがあります。データベースのヘルス状態が変化した時点と、起動ログに最初のImmich接続エラーが出た時点を比較してください。

単純な起動順序では、必要なサービスが実際に準備できる前に、依存するコンテナが起動することがあります。Composeのバージョンとサービス定義が対応している場合は、ヘルス状態に基づく依存関係チェックによって、「コンテナが起動した」状態と「依存サービスが準備できた」状態を区別できます。これを使って、遅い、または正常でない依存サービスを隠すのではなく、不要な再接続ループを取り除いてください。

準備状態のチェックは、狭い範囲で意味のあるものにしてください。データベースのチェックでは、Immichが必要とする接続を受け付けられることを確認すべきであり、それ自体が遅延を追加する高コストなクエリを実行してはいけません。データベースの準備が常にImmichの起動に先行するようになったら、他の変更を加える前にホストの再起動テストを繰り返してください。

-15% OFF

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

Single board computer zimaboard2

再試行ループと正当な起動処理を切り分ける

ストレージとPostgreSQLの準備ができているのに、再起動後もImmichの起動に大幅な時間がかかる場合は、アプリケーションとワーカーのログで、接続失敗の繰り返し、ヘルスチェックの失敗、マイグレーション、ジョブの初期化、リソース不足を調べてください。一定間隔で同じエラーが繰り返される場合は待機中である可能性が高く、CPUやディスクの処理が継続しながら進展している場合は、実際の起動処理である可能性が高いでしょう。

依存関係の順序制御は、短い固定遅延ではなく、意味のあるヘルスチェックと組み合わせると最も効果的です。Composeのヘルスチェックパターンを使うと、初期化中のデータベースやキャッシュとアプリケーションが競合して起動するのを防げます。チェックは現実的な内容にしてください。間隔を短くして不調なサービスを正常に見せても、起動は改善しません。

起動中に再起動回数が増えている場合は、その再起動の連鎖をいったん止め、CPU、メモリ、イメージの起動パラメーターを調整する前に、最初に利用できなくなった依存コンポーネントを特定してください。コンテナの再起動ループを引き起こす依存関係のチェックを使うと、遅い前提サービスの問題とImmich内部の問題を切り分けられます。

もう一度再起動し、実際に使えるまでの時間を確認する

対象を1つだけ変更したら、ホストを完全に再起動し、同じタイムスタンプを記録します。本当の改善であれば、依存サービスの準備完了からImmichを使えるクライアント状態になるまでの時間が短くなり、新たな再起動ループ、マウント漏れ、バックグラウンドエラーが発生しないはずです。

Webのログインページだけで判断しないでください。古い写真を複数開き、検索を実行し、代表的な動画を読み込み、モバイルクライアントが接続できることを確認し、使い捨てのアセットを1つアップロードして、読み取りと書き込みの両方をテストします。家庭で通常の操作ができるようになるまで、サーバーが「起動した」とは言えません。

最初のテストに成功した後、もう一度再起動して、結果がキャッシュの偶然や一時的なネットワークタイミングによるものではないことを確認します。起動が安定しない場合は、起動時のトレースを保存し、実行ごとに準備状態が変動するコンポーネントに集中してください。より良い準備状態のシグナルがない場合を除き、固定遅延を長くして変動を隠さないでください。