Immichが夜間にディスクアクセスを繰り返すのはなぜですか？
Immichでは、スケジュールされたメンテナンス、データベース処理、キューに入ったメディアジョブ、またはリトライが、利用者がライブラリの使用をやめた後も続くことで、夜間にディスクアクティビティが繰り返し発生することがあります。
家庭内が静かだからといって、サーバーがアイドル状態とは限りません。重要なのは、同じプロセスやジョブが、同じ時刻の読み取りまたは書き込みを説明できるかどうかです。まずアクティビティを関連付け、その後で、それが想定内の処理なのか、滞留処理の消化なのか、それとも停止すべきループなのかを判断します。
何かを変更する前に、ディスクスパイクと時刻を照合する
一度だけのノイズの多い観測ではなく、まず3晩分のタイムスタンプを記録します。ブロックI/Oが増加した時刻、負荷の高いデバイス、読み取りと書き込みのどちらが優勢か、そしてパターンがほぼ同じ時刻に始まるかを記録してください。開始時刻が一定ならスケジューラーが原因である可能性があり、不規則なパターンなら、新たな到着、リトライ、または別のコンテナをより強く疑えます。
Immichの環境では、データベースバックアップや整合性に関わる処理を利用の少ない時間帯にスケジュールできるため、早朝のスパイクは意図的な場合があります。ディスクを起動させるという理由だけでジョブを無効にしないでください。まず、そのアクティビティの時間帯の後に、対応するバックアップ、メンテナンス結果、またはキューの完了が現れているかを確認します。
ZimaSpaceのImmichのアイドル時間帯のバックグラウンド処理に関する診断でも、同じタイムスタンプの原則を用いています。「アイドル」を障害状態とみなす前に、目に見える症状をプロセスやジョブと結び付けてください。
PostgreSQLの書き込みとメディアの読み取りを分離する
新しい写真を開いていない場合でも、Immichのアプリケーション状態の変化によってPostgreSQLがアクティブなままになることがあります。データベースのチェックポイント、先行書き込みログ、VACUUM関連の処理、通常のアプリケーション更新は、何千ものメディアファイルをスキャンする場合とは異なるI/Oパターンを示します。フォトライブラリを疑う前に、トラフィックを受けているパスまたはデバイスを特定してください。
pg_stat_ioの分析に関するPostgreSQLの可観測性の解説では、読み取り、書き込み、バックエンドのアクティビティ、チェックポインターの動作、バックグラウンド書き込みを分けて考える必要性が説明されています。この区別を使って、データベースデバイスがビジーなのは有用なトランザクションが永続化されているためなのか、それとも何かが繰り返し処理を発生させているためなのかを確認します。
データベースの書き込みが小規模かつ定期的で、メディアディスクがスリープ状態のままなら、通常のデータベースハウスキーピングである可能性があります。同じデータベースファイルへの大量の書き込みが継続し、ジョブが進行していない場合は、ライブラリ全体を高速ストレージに移すのではなく、ログを保存して原因となっているクエリや再起動ループを調査してください。
バックグラウンドキューが実際に進行しているか確認する
夜間の時間帯の前後で、保留中、実行中、失敗、完了のジョブ数を比較します。サムネイル生成、動画処理、メタデータ抽出、機械学習タスク、またはインポートしたライブラリの処理は、大きな変更の後にストレージをアクティブにし続ける正当な理由になります。滞留が減少しているなら、有用な処理が進んでいる証拠です。
原因不明の読み取りが継続するケースに関する最近のコミュニティ報告は、異なる診断上の境界を示しています。想定される処理がないのに非常に高い読み取りが継続する場合は、「Immichでは普通のこと」として扱わず、調査すべきです。報告された速度は、基準値ではなく一つの事例として扱ってください。
同じ少数のジョブが失敗してキューに再登録されると、進展がないままディスクアクティビティが繰り返されることがあります。最初のエラーと影響を受けたアセットを1件記録し、そのジョブ種別を切り分けてください。ループの原因が単一ファイル、権限、ストレージ遅延、またはサービス依存関係のどれなのかを確認する前に、すべてのキューを消去したり、ライブラリ全体を再生成したりしないでください。
ドライブのノイズから推測せず、I/Oをプロセスに割り当てる
次に発生した際にホストレベルのI/O監視を使い、デバイスを読み書きしているプロセスを特定します。その後、そのプロセスがImmichサーバー、PostgreSQL、機械学習、バックアップツール、ウイルス対策、ファイルシステムのスクラブ、または無関係なコンテナのどれに該当するかを確認します。ドライブのLEDやファンの音だけでは、その所有者を特定できません。
実用的なiotopのワークフローは、プロセスを起点に調査する方法を示しています。短いバーストは観測の合間に消える可能性があるため、複数回サンプルを記録してください。目的は、症状と同じ時間帯に処理を行っているプロセスを捉えることです。
ImmichがI/Oの最大の所有者でないなら、Immichの設定を変更するのをやめ、実際のプロセスを追跡してください。PostgreSQL、Immich、または関連ワーカーが原因なら、そのログとジョブの進行状況をI/Oサンプルと照合します。これにより、「毎晩サーバーが騒がしい」という状態を、具体的なコンポーネントとトリガーに落とし込めます。
正常な夜間処理と障害の境界を定める
既知のスケジュールまたは最近のライブラリ変更に合わせて処理が始まり、有用な作業を完了し、失敗数が増加せず、ストレージのレイテンシとキューの深さが基準値に戻るなら、そのアクティビティは正常と考えられます。通常の所要時間を記録しておけば、将来の増加と比較できます。
頻繁なデータベース書き込みに関する過去のImmichの議論は、目に見えるユーザー操作がなくても一部のデータベースアクティビティが発生し得る理由を示しています。バージョンや環境は変化するため、この事例はデータベースを個別に測定する根拠としてのみ利用し、継続的な書き込みがすべて正常だと判断する根拠にはしないでください。
キューが停止した後もI/Oが続く、同じエラーが繰り返される、ストレージのレイテンシが日中の利用に影響する、空き容量が予期せず減少する、または夜ごとにパターンが悪化する場合は、エスカレーションしてください。大きな変更を加える前に、タイムスタンプ、プロセスI/O、ジョブ数、関連ログ、ファイルシステムの空き容量、再現可能なトリガーを1件保存します。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
