Immichに設定すべきメモリ上限は？

エヴァ・ウォン

IceWhale author

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

What Memory Limit Should You Set for Immich? - Zima Store Online

Immichのメモリ上限を、誰にでも当てはまるGB単位の数値で一律に設定しないでください。ホスト全体のRAM目標とコンテナ単位の上限は、異なる問題を解決します。ホストはスタック全体を支える必要がある一方、コンテナの上限は、正当なImmichの処理を停止させることなくホストを保護する必要があります。

処理済みライブラリの閲覧は軽く見えても、低温状態のマシンラーニング起動、大量インポート、サムネイル生成、顔認識、動画処理では、はるかに多くのメモリを消費することがあります。実際に必要な最も重いワークロードを測定し、PostgreSQLとオペレーティングシステム用の余裕を確保してください。OOMによる強制終了が繰り返されるなら、それは通常のスロットリングではなく、設定した上限が失敗していると考えてください。

上限を決める前にメモリ負荷を測定する

メモリを3つの状態で記録します。アイドル状態での閲覧、日常的なアップロードを再現した状態、そして計画しているバックグラウンド処理の中で最も重い状態です。コンテナの使用量、ホストの利用可能メモリ、スワップの活動、OOMイベント、ジョブが処理を継続できているかを記録してください。Linuxのメモリ会計には、回収動作が異なる複数種類のメモリが含まれるため、docker statsで確認できる単一のピーク値だけでは不十分です。

有用なDocker cgroupのメモリ内訳では、生の合計値をすべて同じ危険度として扱うのではなく、匿名メモリ、ファイルバックキャッシュ、スラブを分けて確認できます。ホストに十分な余裕があり、ファイルキャッシュが安定している状態は、匿名メモリが増え続けたり、スワップ負荷が高まったり、同じImmichジョブの実行中にcgroupのOOMカウンターが増加したりする状態とは異なります。

再現可能な最大使用量を特定し、それが主に回収可能なキャッシュなのか、アクティブな作業メモリなのかを説明できれば、この段階は完了です。ワークロードを変えていないのに使用量が増え続ける場合、コンテナが繰り返しOOMで強制終了される場合、またはホストが激しくスワップし始めた場合は、その実行結果を基準にサイズを決めず、まず異常な増加の原因を調べてください。

正当なImmichの最重量ワークロードを基準に上限を決める

上限を適用した後もサポートすべきワークロードを選びます。ある家庭では、4台のスマートフォンがアップロードを続ける中でSmart Searchと顔認識ジョブを処理する状態かもしれません。別の家庭では、大量の初回インポート後に通常の閲覧を行う状態かもしれません。上限が明確なサービス水準を反映するよう、測定中はデータセット、モデル、同時実行設定、その他のコンテナを固定してください。

短時間のバーストに対応できる、測定可能な余裕を持たせたうえで、観測された回収不能メモリのピークより高い位置にハード上限を設定します。同時に、PostgreSQL、ファイルシステムキャッシュ、コンテナランタイム、無関係なサービスのためにホストメモリを残してください。関連するZimaSpaceのローカルAIのリソースに関する警告サインのチェックリストは有用です。発熱、スワップ、突然の再起動から、Immichだけのグラフでは見落としやすいホストレベルの負荷を確認できるためです。「コンテナが一度上限に達した」ことを、RAMを増やす必要がある証拠と解釈しないでください。重要なのは、同じ正当なワークロードで処理が大幅に遅くなったり、ジョブが失われたり、スワップが継続したり、OOMで強制終了されたりするかどうかです。逆に、Immichが自身のcgroup上限に達する前にデータベースやホストのリソースを奪えるなら、その上限は緩すぎます。

異常な増加に対して上限を引き上げる前にワークロードを減らす

提案した上限が特定のバックグラウンド処理でのみ失敗する場合は、上限を引き上げる前に、そのジョブの同時実行数を減らすか、処理段階を分離してください。マシンラーニング、サムネイル生成、動画処理、データベース処理では、メモリ使用の特性が異なることがあります。アクティブなバッチを小さくすれば処理は遅くなっても、家庭内のインターフェースの応答性とホストの復旧可能性を維持できます。

バージョン固有の障害も重要です。Immich v3.0.3のメモリ報告では、ロケール関連の異常な条件により、マシンラーニングワーカーの使用量が増加し、cgroupの上限に達してOOMが発生したと説明されています。この事例は、通常のImmichのRAM使用量を示すものではありません。原因不明の増加が見られた場合、ホストの予算を恒久的に増やす前に、ソフトウェアまたは設定に起因する問題として切り分ける必要があることを示しています。

同時実行数、モデル、バージョンのいずれか1つを変更したら、同じワークロードを再実行してください。メモリの使用パターンと元のジョブの両方が、期待した方向に改善した場合にのみ、その変更を維持します。メモリが安定した水準に近づかず上昇し続ける場合は、ログとバージョンの詳細を保存し、ハード上限を際限なく大きくするのではなく、エスカレーションしてください。

Featured

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

ZimaCube2

コールド再起動と高負荷サイクルの後に上限を検証する

キャッシュとモデルの常駐が既知のコールド状態から始まるよう、ホストを再起動します。通常のログインと閲覧を確認し、その後、代表的なアップロードとバックグラウンド処理を実行してください。匿名メモリのピーク、キャッシュ、スワップ、OOMカウンター、データベースの応答、キューの処理完了時間、他の重要なコンテナが応答し続けているかを記録します。

合格となる上限は、コールドスタートと通常時の最繁忙サイクルの両方を、OOMによる強制終了、継続的なスワップスラッシング、コンテナの繰り返し再起動、キューの処理停止なしで乗り切れる必要があります。また、Immichが高負荷のときでも、データベースのダンプや管理者ログインなどの復旧作業に必要なホストの余裕を残している必要があります。

定義した家庭内のワークロードがすべて問題なく通過し、人工的なストレステストだけが失敗する場合は、必要のないシナリオのためにRAMを購入するのではなく、許容する境界を記録してください。

実際のワークロードがホストを使い果たさずに完了できない場合は、同時実行数を減らす、マシンラーニングを分離する、メモリを増設する、または競合するサービスを別の場所へ移してください。その後、同じ検証を繰り返してから、新しい上限が安全だと判断してください。