大量のモバイルインポート中に Immich のサムネイルと ML ストレージが増えるのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Immich Thumbnail and ML Storage Grow During Large Mobile Imports? - Zima Store Online

大規模なインポートでは、各アセットから派生ファイルやデータベースレコードが生成されるため、通常はImmichのストレージ使用量が増加します。一方、ダウンロードしたモデルは別のキャッシュを占有します。

ある家族が何年分ものスマートフォンの写真を自宅のNASに移したところ、アップロードカウンターが完了した後も空き容量が減り続けました。これは、元の写真がすべてもう一つ複製されたのではなく、正当なバックグラウンド処理が続いている可能性があります。重要なのは、アセットごとに生成されるファイル、共有モデルファイル、そして完了した処理量に対応しないまま増え続けるデータを区別することです。

1回のアップロードで複数種類の状態が作られる

アップロードされたオリジナルは、完成したライブラリの一部にすぎません。Immichは閲覧用の小さな表現も作成し、アセットと所有者、日付、アルバム、検索機能を結び付ける情報を保存します。これらの出力はそれぞれ異なるリクエストに利用されるため、ネットワーク転送が完了しても、後続の書き込みがすべて終わったことにはなりません。

ここではメディアファイルとデータベースレコードの区別が重要です。アプリケーションのメタデータや検索用エンベディングはPostgreSQLに保存され、フル解像度の写真が追加されるわけではありません。機械学習サービスがアプリケーションで使う結果を計算します。したがって、追加されたバイト数をすべてオリジナルの重複とみなすと、通常のインポートによる増加を誤って説明することになります。

スマートフォンからの転送が完了しても、サーバーが受け付けたバッチを処理し続けている場合を考えてみましょう。オリジナルはすでにディスク上で安定していても、プレビューや検索可能なレコードは引き続き生成されることがあります。ストレージを同じ処理段階で比較してください。アップロード直後のコホートと、完全に処理されたコホートは同等のサンプルではありません。

オリジナルのギガバイト数よりアセット数が重要

サムネイルの容量を計画する場合、総オリジナル容量よりも、アセットの数と種類のほうが実態を説明しやすいことがあります。小さな写真1,000枚と長時間の動画数本は、元データの容量が同程度でも、必要となる画像派生ファイルの数は大きく異なります。プレビューの寸法、圧縮設定、画像内容によっても生成されるバイト数は変わります。

公開されているサムネイル容量の測定例も、そのばらつきを示しています。ある所有者は70 GBのライブラリで6.3 GB、別の所有者は写真と動画2 TBで約370 GBと報告しました。これらは個別の構成における数値であり、比較可能な管理下のベンチマークではありません。フォーラムの単一の割合をそのまま採用すると、別の家庭では実態と異なる見積もりになる可能性があります。

例として、測定された画像派生ファイルの平均が250 KBのアセットが100,000個ある場合、10進単位で約25 GBが必要です。1個あたり500 KBなら、同じ数で約50 GBになります。どちらの数値にも、オリジナル、エンコード済み動画、データベースの増加、バックアップは含まれません。この例は、普遍的な余裕容量を推奨するものではなく、アセット単位の関係だけを示しています。

モデルファイルと検索レコードは異なる増え方をする

モデルキャッシュには再利用可能なモデルファイルが保存されますが、検索ベクトルは個々のアセットを表します。ダウンロード済みモデルのセットが固定されている場合、写真を追加するたびにモデル全体を新たにダウンロードする必要はありません。一方、モデルを追加または変更すると、アップロード済み写真の数とは関係なく、キャッシュ容量が段階的に増えることがあります。

ある実地のポータブル構成では、ライブラリ、モデルキャッシュ、PostgreSQLのデータを別々の永続ディレクトリに保存しています。この分離により、1つにまとめられたDockerのサイズが機械学習の出力を表すと決めつけずに、それぞれのストレージ用途を確認できます。これは古いリリースの構成例であり、現在のインストール手順や推奨コンテナタグの一覧ではありません。

ディスク使用量と、メモリに読み込まれた状態も区別してください。モデルはディスク上に残ったまま、メモリ上のコピーだけが解放されることがあります。また、ファイルシステムキャッシュによって報告メモリが増えても、永続ファイルが増えたとは限りません。急増の原因を説明するには、コンテナ名から結論を出す前に、どのディレクトリが所有しているか、どの設定が変わったかを特定してください。

-15% OFF

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

Single board computer zimaboard2

通常の増加では説明できなくなる場合

派生ファイルの通常の増加には、固定された設定で処理される固定数のオリジナルという上限があります。新しい元アセットが際限なく増え続けることはありません。予定していたインポートがすべて停止した後もアセット数が増え続けるなら、検出パス、繰り返しの取り込み、または別の新しい処理対象を説明に含める必要があります。

確認された再帰的スキャンの事例では、Immichのアップロード先が外部ライブラリ内に含まれていました。その結果、生成されたサムネイルが新しい画像として扱われ、派生ファイルからさらに派生ファイルが作られました。これは大規模なモバイルアップロードとは異なる因果メカニズムであり、規模の大きいライブラリが自然に無制限で増殖する証拠として扱ってはなりません。

コンテナの書き込み可能レイヤーで異常な増加が起きる場合も、別のカテゴリーです。2026年の報告では、そこに数百GBが蓄積したと説明されていますが、議論では普遍的な根本原因は確定していません。グラフを正常に見せるために、データベースファイル、メディア、Docker内部データを削除しないでください。まず、どの用途のデータが増えているのか、完了した処理で説明できるのかを確認します。

ストレージの用途別にインポートを測定する

代表的なインポートの前に、オリジナルのアセット数と容量、サムネイルとプレビューの容量、エンコード済み動画の容量、データベースサイズ、モデルキャッシュサイズ、一時ファイルやログの増加量を記録します。同じコホートで有効化されている処理ジョブが完了した後に、もう一度測定します。インポートと同時に設定を変更したのではなく、差分をインポートに帰属できるよう、メディア設定は変えないでください。

ストレージの内訳を把握しても、家族向けバックアップ計画の代わりにはなりません。実用的な写真サービスには、保護されたオリジナルと、ライブラリを復元するために必要なアプリケーション状態が必要です。サムネイルディレクトリだけでは、家庭のコレクションを保存できません。容量を節約する実験が思い出の唯一のコピーにならないよう、この保護作業は再生成可能なデータの使用量測定とは分けて考えてください。

測定した用途別の合計で追加されたバイト数を説明でき、予期しない元アセットが増え続けていなければ、その結果を受け入れられます。モデルの構成が変わっていないのにキャッシュや書き込み可能レイヤーの増加が続く場合、または派生ファイルが再び検出対象に入っている場合は、別のメカニズムを調査してください。このテストはストレージが増えた理由を明らかにするものであり、説明を破壊的なクリーンアップ手順に変えるものではありません。