大規模なモバイルライブラリのインポート中に、Immichで断続的なエラーが発生するのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Immich Return Intermittent Errors During Large Mobile-Library Imports? - Zima Store Online

大規模なモバイルインポート中にImmichで断続的にエラーが発生する場合、通常はライブラリ全体やアップロードしたすべてのアセットが破損しているのではなく、複数の処理が重なることでどこか1つの層に障害が起きています。

大規模なインポートでは、モバイルのバックグラウンド動作、長時間のリクエスト、リバースプロキシやトンネルの制限、データベースへの書き込み、ストレージI/O、サムネイルや動画の処理、機械学習キューが同時に関係します。まず、失敗したアセットの小さなグループとタイムスタンプを記録してください。そのうえで、障害がスマートフォン、ネットワーク経路、アプリケーションサーバー、または負荷が集中した依存サービスのどこで始まっているかを特定します。

すべてを再試行する前に、エラーのグループを分類する

失敗を、メディアの種類、ファイルサイズ、送信元デバイス、ネットワーク経路、発生時刻ごとに分類します。大きな動画だけが失敗する場合は、CPUより先にリクエスト時間とアップロード制限を調べてください。ランダムな写真や動画が同じ混雑時間帯に失敗する場合は、共有サーバーリソースやネットワークの不安定さが有力な候補になります。

2026年のImmichユーザーレポートである多数のモバイルアップロードエラーは、大量のスマートフォン内の未処理データによって、アセットごとおよび経路ごとの診断が必要な失敗が繰り返し表面化する例として参考になります。ただし、これによってモバイルクライアントに普遍的な単一のバグがあるとは限りません。

最初の診断として「すべて再試行」を選択しないでください。失敗したアセットの名前またはIDを10件、成功した比較対象を1件、対応するクライアントとサーバーのログ期間とともに保存します。既知の小さな対象グループがあれば、元の証拠を隠してしまう新たな大量エラーを発生させずに変更をテストできます。

ローカルアップロードと通常のリモート経路を比較する

同じ小さいテストファイルと大きいテストファイルを、安定したローカルWi-Fi経由で信頼できるローカルエンドポイントに直接アップロードし、その後、通常使用しているリモートホスト名、VPN、トンネル、またはリバースプロキシ経由でも繰り返します。経路が主な変数になるよう、アカウントとアセットは同じものにしてください。

大容量ファイルのバックアップ失敗に関するレポートは、プロキシやトンネルのリクエスト制限をこの分岐で確認すべき理由を示しています。報告されたサービスやしきい値は環境によって異なります。一般的なテストでは、直接のローカル転送は成功する一方で、リモート経路だけが一貫して失敗するかを確認します。

同じアセットが両方の経路で失敗する場合は、サーバーとストレージの証拠を追ってください。リモート経路だけが失敗する場合は、最大ボディサイズ、リクエストのバッファリング、アイドルおよび読み取りタイムアウト、TLS終端、モバイルネットワークの切り替え、再送を調べます。サムネイルの同時実行数を変更しても、Immichにリクエスト全体が届いていなければ修復にはなりません。

エラーをキューの増加やリソース圧迫と関連付ける

大規模なインポートでは、バックグラウンドジョブが蓄積している間もアップロードを受け付け続けることがあります。障害が発生した時間帯に、CPU、メモリプレッシャー、ブロックI/Oレイテンシ、データベースの応答性、コンテナの再起動、ジョブの完了状況を観察します。使用率が高いだけでは証拠になりません。エラーと同じタイミングでメトリクスが変化している必要があります。

コンテナのCPU、メモリ、ネットワーク、ディスクのメトリクスに関するDockerのリソース監視記事は、ホスト全体の平均値だけでなく、コンテナ同士を比較する有用性を示しています。Linuxでは、同じタイムスタンプのホスト側ストレージとメモリプレッシャーの証拠をコンテナメトリクスと組み合わせてください。

メモリプレッシャーによってコンテナが終了する、アップロードエラーとともにストレージレイテンシが上昇する、またはキューの進行が止まる一方でデータベースの応答時間が急増する場合は、原因となっているワークロードまたは同時実行数だけを減らし、固定した対象グループで再テストします。リソースグラフが安定している場合は、アプリケーションログとネットワーク経路の診断を続けてください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

エラー率とテールレイテンシを負荷の兆候として扱う

平均応答時間では正常に見えるシステムでも、ピーク時には少数のリクエストがタイムアウトすることがあります。管理した時間枠で、試行したアップロード数、失敗数、応答時間の中央値、遅い側のリクエストを記録します。これにより、「断続的」という状態を主観的な印象ではなく測定可能なものにできます。

エラーとレイテンシの分析における負荷テストのフレームワークでは、ステータスクラス、接続問題、分布、時系列の相関を分析することが推奨されています。家族のライブラリに対して過度な負荷をかける必要はありません。実際のインポート速度に同じ分析構造を適用してください。

到着率を大幅に下げると失敗が減り、各アセットが個別にはすべて成功する場合、現在のスタックにはそのインポート強度に対応する余裕がありません。同じファイルが1件ずつでも失敗する場合は、一般的な飽和ではなく、アセット固有、経路固有、または決定的なソフトウェアエラーが原因です。

1つの負荷要因だけを減らし、同じインポートパターンで再テストする

証拠から予測される、最も安全な変更を1つ選びます。たとえば、バックグラウンドの同時実行数を1つだけ減らす、別の負荷の高いコンテナを一時停止する、ローカル経路を使用する、バックアップ時間帯以外にインポートする、またはプロキシのタイムアウトを修正します。CPU制限、ストレージ、プロキシルール、アプリのバージョンを同時に変更しないでください。

スマートフォンの写真バックアップの中断に関するZimaSpaceのワークフローでは、モバイル側の分岐を確認できます。バックグラウンドスケジュール、クラウドのみのオリジナル、ネットワーク状況の変化によって、サーバーが正常でもアップロードが中断されることがあります。

固定した対象グループが成功し、同じ大規模インポートを安定したエラー率、進行するキュー、許容できる対話性能で実行できれば解決と判断します。低負荷でも失敗が続く場合や、同じアセットで繰り返し発生する場合は、クライアントログ、サーバーログ、プロキシのステータス、リソースグラフ、ファイルの種類とサイズ、最初に失敗したリクエストを含めてエスカレーションしてください。