著者 Matt Connor
Immichに必要なRAMとディスク容量は？
Immichの公式最小要件はRAM 6 GBです。サーバー、Postgres、Redis、機械学習の必要量を分解し、RAM 4 GBで動かす場合の設定と注意点を説明します。
Immich に必要な RAM 量
Immich の公式ドキュメント上の最小要件は 6 GB の RAM（ランダムアクセスメモリ）で、推奨値は 8 GB です。CPU は最低限 2 コア、余裕のある構成では 4 コアを想定しています。この値はスタック全体を対象としています。Immich は 1 つのアプリケーションではなく、4 つのコンテナで構成されるためです。すでにインポート済みのライブラリを閲覧するだけなら、必要なメモリは少量です。メモリを消費するのはインポート処理で、その大部分は停止できる 1 つのコンテナが使用します。
このグラフのデータ
[
{
"label": "Documented minimum",
"ram_gb": 6,
"cpu_cores": 2
},
{
"label": "Documented recommended",
"ram_gb": 8,
"cpu_cores": 4
}
]これらは、2026 年 10 月時点で Immich の要件ページに記載されている数値です。これはサイジングの推奨値であり、起動時にソフトウェアが実行可能かどうかを確認する値ではありません。同じページには、機械学習機能を無効にした 4 GB の小規模構成も記載されています。それ未満の構成は示されていません。小規模なサーバーで変わるのは、どのバックグラウンドジョブが完了するか、またメモリ不足時にインポート処理がどう動作するかです。
明確なハード要件が 1 つあります。version 3 以降、amd64 ホスト上の機械学習コンテナには x86-64-v2 CPU が必要です。これは、おおむね 2012 年以降に販売されたプロセッサの大半が満たします。この要件はサーバー全体ではなく、そのコンテナに適用されます。そのため、古いハードウェアでは機械学習を無効にするか、以下で説明するように別のマシンで実行できます。または、Immich のドキュメントで互換性を持つ最後のバージョンとされている v2.7.5 を使うこともできます。
まだインストールしていない場合は、まず Docker Compose を使った VPS への Immich 完全インストールを参照し、ここに戻ってサーバーの構成を決めてください。
メモリの内訳: 4 つのコンテナ
公式の Compose ファイルは 4 つのサービスを起動します。各サービスのメモリ使用特性は異なるため、合計値だけでは重要な内訳が分かりません。
immich-server は Web インターフェイスと API を提供し、バックグラウンドジョブのワーカーも実行します。1 つのコンテナ内で 2 つのワーカーが動作します。api はブラウザーとモバイルアプリからのリクエストに応答します。microservices は、サムネイル生成や動画エンコードを含むキューを処理します。変数 IMMICH_WORKERS_INCLUDE と IMMICH_WORKERS_EXCLUDE を使うと、この 2 つを別々のコンテナに分離できます。これにより、負荷の大きい側に専用のメモリ上限を設定し、写真を提供する側を制限せずに済みます。
database は、VectorChord 拡張機能を組み込んだ PostgreSQL 14 イメージです。すべてのメタデータと、アセットごとに 1 つの検索ベクトルを保持します。Immich のドキュメントでは、このサービスにだけスタック内で明示的な下限を設定しています。Docker のリソース制限を適用する場合、データベースには少なくとも 2 GB が必要です。同じページでは、データベースはできればローカル SSD ストレージに配置し、種類を問わずネットワーク共有には置かないよう求めています。ベクトル検索とインデックス検索は小さなランダム読み取りになるため、ネットワークボリュームではそのたびに往復通信が発生するからです。プランの選択がこの点に左右される場合、VPS における NVMe と SATA SSD ストレージの違いは、このスタックの他の部分よりもここで大きく影響します。
redis は Valkey イメージを実行し、ジョブキューを保持します。写真データではなくジョブのレコードを保存するため、4 つの中でメモリ使用量は大幅に少なくなります。
immich-machine-learning は、必要なプランサイズを決めるサービスです。スマート検索、顔検出、テキスト認識用のモデルを読み込み、読み込んだモデルはメモリ上に常駐します。MACHINE_LEARNING_MODEL_TTL のデフォルト値は 300 です。そのため、5 分間リクエストがないとモデルは破棄され、次のリクエスト時に /cache ボリュームから再度読み込まれます。一括インポート中は 5 分間空くことがないため、最初のアセットから最後のアセットまでモデルは読み込まれたままになります。
インポート中に発生する変化
アイドル状態の Immich は静かです。小規模なサーバーで問題が発生するのはインポート中です。1 つのアセットをアップロードすると、一連のジョブがキューに入り、複数のキューが同時に実行されるためです。
メタデータの抽出ではファイルヘッダーを読み取ります。負荷は軽い処理です。サムネイルの生成は、より負荷が高い処理です。Immich はアセットごとに 3 種類のサムネイルを生成します。ぼかした thumbhash プレースホルダー、WebP プレビュー、JPEG サムネイルです。さらに、検出した顔ごとにサムネイルを 1 つ追加で生成します。これらの各ジョブでは画像をデコードします。ジョブの並列度によって、同時にデコードする数が決まります。並列度は、ジョブ単位の小さな負荷をサーバー全体の負荷に拡大する要因です。そのため、Immich FAQ では、リソースが限られたマシンで最初に下げる設定として並列度を挙げています。Administration の Settings、Job Settings で、負荷の高いキューの並列度を 1 に設定します。
動画アセットではトランスコードも発生します。各トランスコードジョブは、それぞれ専用のメモリを使用する独立した FFmpeg プロセスです。許可したすべての CPU スレッドを使用します。
Smart search では、新しいアセットをすべて machine learning コンテナに送り、1 つの埋め込みベクトルを計算します。顔検出では、同じ画像に対して 2 つ目のモデルを実行します。既存の写真ライブラリを最初にインポートすると、これら 2 つのキューが所有するすべてのアセットを対象に数時間実行されます。インストール全体でメモリ使用量が最も高くなるのはこの時点です。この処理は 1 回だけ発生します。
顔認識と物体認識で最も多くの RAM が必要になる理由
顔の処理には 2 つの処理があります。顔検出では機械学習コンテナ内のモデルを実行し、顔の位置を示すボックスを検出します。続く顔認識では、検出結果を人物ごとにまとめます。この処理では Postgres のベクトルインデックスを検索します。そのため、ライブラリが大きいと、まず検出中のモデルコンテナ、次にグループ化中のデータベースへ順番に負荷がかかります。
次の 4 つの設定によって、機械学習コンテナが保持するデータ量が変わります。
- 顔モデル。Immich はデフォルトで
buffalo_lを使用し、FAQ では小規模なサーバーにbuffalo_sを推奨しています。こちらは小型のモデルなので、メモリ使用量が少なく、処理も高速です。ただし、小さな顔や横向きの顔では精度が低下します。 - ワーカー数。
MACHINE_LEARNING_WORKERSのデフォルト値は 1 です。各ワーカーは、モデルのコピーをそれぞれ読み込む独立したプロセスです。そのため、2 にすると常駐モデルメモリはおよそ 2 倍になります。十分な RAM がない限り、1 のままにしてください。 - バッチサイズ。
MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITIONは一度に処理する顔の数を制限します。バッチはまとめてメモリ上に保持されるため、40 人が写った集合写真は、1 人のポートレートより多くのメモリを使用します。 - 実行するモデルの種類。スマート検索、顔検出、テキスト認識は、それぞれ専用のモデルを読み込みます。Administration、Settings、Machine Learning Settings で使用しない機能を無効にすると、インポートの実行中だけでなく、継続的にそのメモリ使用量を削減できます。
MACHINE_LEARNING_MODEL_ARENA もあります。これはメモリの断片化を防ぐために CPU メモリを事前に割り当てる設定で、デフォルトでは有効です。この設定の変更は最後に行ってください。効果は使用しているメモリアロケーターに依存するため、判断するには変更前後の docker stats を監視するしかありません。
3 つの構成例: 2 GB、4 GB、8 GB
このグラフのデータ
[
{
"label": "2 GB VPS",
"server_limit_mb": 768,
"db_limit_mb": 768,
"ml_limit_mb": 0,
"redis_limit_mb": 128,
"notes": "below every documented configuration, machine learning container removed"
},
{
"label": "4 GB VPS",
"server_limit_mb": 1024,
"db_limit_mb": 2048,
"ml_limit_mb": 0,
"redis_limit_mb": 192,
"notes": "documented 4 GB setup: machine learning disabled or moved to another host, job concurrency 1"
},
{
"label": "8 GB VPS",
"server_limit_mb": 2048,
"db_limit_mb": 2048,
"ml_limit_mb": 2560,
"redis_limit_mb": 256,
"notes": "everything on at default settings"
}
]これらは Immich が使用するメモリ量ではなく、Compose に設定する上限として扱ってください。上限は最大値です。リソースを予約するものでも、サービスを小さくするものでもありません。ホストのメモリが不足したときに、どのサービスをカーネルが kill するかを決めます。この判断は、カーネル独自のスコアリングに任せるより、運用者が行うほうが適切です。
2 GB のサーバー: machine learning コンテナを削除する
2 GB は、ドキュメントに記載された最小値 6 GB を下回ります。また、Immich が記載している唯一の縮小構成である、machine learning を無効にした 4 GB 構成も下回ります。Immich は 2 GB 構成を公開していないため、この構成はレシピではなく、サポート対象外の妥協案です。それでも試す場合は、docker-compose.yml 内の immich-machine-learning サービス全体をコメントアウトしてください。または、サービスを起動したまま、Administration、Settings、Machine Learning Settings ですべてのモデルを無効にします。コンテナを削除するほうが確実です。モデルを無効にしても、Python プロセスはメモリ上に残るためです。
アップロード、アルバム、共有、モバイルバックアップ、サムネイル、日付・場所・ファイル名による検索は利用できます。説明による検索、顔の自動グループ化、画像内のテキスト認識は利用できません。
4 つの上限の合計は約 1.7 GB で、ホストには約 300 MB が残ります。Immich のドキュメントでは、Docker のリソース制限を使用する場合、データベースだけで少なくとも 2 GB が必要とされています。これはホスト全体の容量と同じです。そのため、データベースに 768 MB を設定するのは、この下限を大きく下回ります。この構成では、Postgres が最も kill されやすいサービスになります。
最初に問題が発生するのはインポートです。ページの表示はメタデータのクエリとファイルの読み取りで構成されるため、既存のライブラリの閲覧はサーバーへの負荷が比較的小さくなります。一方、動画の多いインポートでは、トランスコードとサムネイル処理のキューが同時にメモリを必要とするため、swap が発生します。2 GB しかない場合は、負荷の大きいすべてのキューの同時実行数を 1 に設定し、swap ファイルを追加してください。プランを選ぶ場合は、4 GB を実質的な下限と考えてください。
4 GB のサーバー: machine learning を有効にし、1 度に 1 ジョブだけ実行する
Immich のドキュメントでは、machine learning 機能を無効にすれば 4 GB で動作可能とされています。要件ページに記載されている縮小構成はこれだけです。データベースを記載上の下限である 2 GB にすると、図の 3 つの上限の合計は約 3.2 GB になり、ホストには約 800 MB が残ります。サムネイル生成のジョブ同時実行数を 1 に設定し、トランスコードのスレッド数を少なくしてください。
顔認識と物体認識を維持するには、以下で説明するように、machine learning コンテナを別のマシンで実行し、このサーバーからそのマシンを参照するのが、ドキュメントに沿った方法です。同じ 4 GB のサーバーで実行すると、Immich の記載範囲を超えます。データベースの下限を確保すると、サーバー、Redis、モデル、ホストに使える容量は合計で約 2 GB しか残らないためです。それでも試す場合は、Compose の上限で machine learning コンテナを制限し、顔認識を buffalo_s に切り替えてください。また、サムネイル生成、顔検出、スマート検索のジョブ同時実行数を 1 に設定します。
既存のライブラリに対する最初の処理には何時間もかかり、大規模なライブラリでは 1 日を超えることがあります。これはメモリではなく CPU の制約です。そのため、RAM を増やしても処理時間は短くなりません。
このサーバーで machine learning を実行する場合、最初の一括処理で最初に問題が発生するのは、そのコンテナです。上限を設定しないと、トランスコードジョブがメモリを消費する間にもコンテナが増大し、カーネルは 2 つのうちメモリ使用量が大きいほうを kill します。数秒以内に再起動するため、docker ps -a では Up と表示され、隣接するコンテナより uptime が大幅に短くなります。Exited (137) ではありません。キューは、前回確認したときよりも静かに遅延しています。
8 GB のサーバー: ドキュメントに記載された推奨構成
8 GB と 4 コアの構成は Immich の推奨値に一致します。スマート検索、顔検出、テキスト認識、トランスコードを、既定の同時実行数で実行できます。10 万を超えるアセットを含むライブラリでも余裕があります。この段階では、負荷の中心はメモリからディスク速度へ移ります。データベースが終日処理するのは、ベクトルインデックスとメタデータクエリだからです。
それでも上限は設定してください。余裕のあるサーバーでも、上限を設定すると、制御不能になった 1 つのキューがデータベースまで停止させる事態を防げます。小さい構成と比較して価格を検討する場合は、メモリ容量別に見た VPS の実際の料金 により、8 GB プランがチューニングを止める最も安価な方法になることが多いでしょう。
Compose の制限でサービスごとのメモリ上限を設定する方法
このために docker-compose.yml を編集しないでください。このファイルは wget でアップグレードするたびに置き換えられます。docker-compose.override.yml に制限を記述してください。docker-compose.override.yml は docker compose と自動的にマージされます。
services:
immich-server:
deploy:
resources:
limits:
memory: 1024M
immich-machine-learning:
deploy:
resources:
limits:
memory: 1024M
cpus: '1.5'
database:
deploy:
resources:
limits:
memory: 2048M
redis:
deploy:
resources:
limits:
memory: 192Mdocker compose up -d
docker stats --no-streamdocker stats の MEM USAGE / LIMIT 列に、ホスト全体のメモリではなく設定した上限が表示されるはずです。制限列にホスト全体のサイズが表示される場合、override ファイルが読み込まれていません。ファイル名を確認し、docker compose config を実行してマージ後の結果を確認してください。
データベースは 2048M 以上に設定してください。Docker のリソース制限を使用する場合、Immich はデータベースの下限として 2 GB を指定しています。制限が低すぎると、サービスの動作が遅くなるだけでなく停止します。コンテナが再起動を繰り返す場合は、上限を引き上げてください。仕組みの詳細は、Docker Compose でサービスごとにメモリ制限を設定する方法を参照してください。Compose v2 では deploy が Swarm 外でも機能する理由も説明しています。
機械学習コンテナを停止または移動する方法
小規模なサーバーでは、このコンテナを別の場所へ移動することが最大の効果をもたらします。Immich は、別のマシンでの実行に対応しています。2 台目のホストで次のファイルを作成します。夜間だけ電源を入れるデスクトップでも構いません。
name: immich_remote_ml
services:
immich-machine-learning:
container_name: immich_machine_learning
image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
volumes:
- model-cache:/cache
restart: always
ports:
- 3003:3003
volumes:
model-cache:docker compose up -d
curl -s http://localhost:3003/ping次に Web インターフェースで Administration、Settings、Machine Learning Settings の順に開き、Add URL をクリックして http://<host>:3003 を入力します。両方のホストで同じバージョンを使用してください。Immich のドキュメントでは、2 台のバージョンが異なるとバグや不安定な動作が発生する可能性があると警告しています。
このポートでは、写真の画像プレビューが暗号化されずに別のマシンへ送信されます。また、Immich のドキュメントでは、機械学習コンテナ自体にはセキュリティ対策がないと警告しています。そのため、プライベートネットワーク上で使用するか、2 台のホスト間に WireGuard トンネルを構成して通信してください。3003 をインターネットに公開してはいけません。
常駐モデルコンテナそのものが問題であれば、プランのサイズを決める前に、PhotoPrism と Immich で停止中に実行される処理がどう異なるかを比較するのも妥当です。
Immich ライブラリにはどの程度のディスク容量が必要ですか？
単一の倍率では計算できません。4 種類のデータが、それぞれ異なる割合で増えるためです。以下は、写真 50,000 枚と短い動画 500 本のライブラリで計算した例です。
このグラフのデータ
[
{
"label": "Originals: 50,000 photos at 4 MB",
"gb": 200
},
{
"label": "Originals: 500 videos at 120 MB",
"gb": 60
},
{
"label": "Thumbnails and encoded video at 15%",
"gb": 39
},
{
"label": "Postgres database",
"gb": 3
},
{
"label": "Machine learning model cache",
"gb": 2
}
]写真の 200 GB と動画の 60 GB は仮定値です。購入前に、自分の平均サイズへ置き換えてください。この容量を左右するのは動画です。スマートフォンで撮影した動画 1 分分は、写真 100 枚より大きくなります。
find /srv/immich/upload -type f -printf '%s\n' \
| awk '{n++; s+=$1} END {printf "%d files, %.1f MB average\n", n, s/n/1048576}'39 GB の行だけが、Immich が公開している比率です。生成されるサムネイルとトランスコード済み動画により、ライブラリのサイズは平均で 10 から 20 パーセント増えます。動画のうち、ブラウザー互換性のために再エンコードが必要な割合によって異なるため、範囲で示されています。JPEG のライブラリは、この範囲の下限に近くなります。
データベースは 3 GB で、ほぼ固定のコストです。Immich のドキュメントでは、データベースファイルは通常 1 から 3 GB とされています。ピクセルではなく、メタデータと検索ベクトルを保持するためです。モデルキャッシュは 2 GB で、複数のモデルを有効にしたり、異なるモデルを試したりすると増加します。FAQ でこの領域が容量を消費すると説明されているのは、このためです。
5 行の合計は 300 GB を少し超えます。そのため、500 GB のボリュームなら増加分の余裕が残りますが、250 GB のボリュームでは不足します。次のコマンドで内訳を確認できます。
grep UPLOAD_LOCATION .env
du -sh /srv/immich/*UPLOAD_LOCATION の下には 6 つのフォルダーがあります。upload と library にはオリジナルが保存され、thumbs にはプレビューと顔サムネイル、encoded-video には再エンコードされたコピー、profile にはアバター、backups には自動データベースダンプが保存されます。upload、library、profile だけが代替できません。それ以外は、これらから再生成できます。
2 つの点で意外に感じることがあります。削除したアセットは最初にゴミ箱へ移動され、ゴミ箱を空にするまで容量を保持します。そのため、大規模な削除を実行した当日は空き容量が増えません。もう 1 つは、データベースダンプにはメタデータしか含まれないことです。ファイルがなければ役に立ちません。
docker exec -t immich_postgres pg_dump --clean --if-exists \
--dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gzこれに加えて、オリジナルのファイルレベルのコピーをサーバー外の場所に保存してください。VPS からサーバー外のストレージへの restic バックアップは、そのために使用します。
CPU がボトルネックであり、RAM ではない
RAM を増やしても、トランスコードは高速化しません。Immich は FFmpeg でトランスコードします。通常の VPS では、すべてのフレームを CPU でデコードおよびエンコードします。各 FFmpeg プロセスは、デコード済みフレームのバッファーをメモリ上に保持します。そのため、インポートの説明ではトランスコードを個別のメモリ消費として数えています。ただし、処理速度を決めるのは CPU です。ハードウェアアクセラレーションを利用できる場合でも、Immich のドキュメントでは、デフォルトではエンコードのみが高速化されると説明されています。そのため、ハードウェアデコードも有効にしない限り、デコードとトーンマッピングは CPU が実行します。
ハードウェアアクセラレーションには、追加の hwaccel.transcoding.yml Compose ファイルと、デバイスのパススルーが必要です。使用できる方式は NVENC、Quick Sync、RKMPP、VAAPI です。多くの VPS プランでは、これらを利用できません。そのため、CPU での処理を前提に計画してください。
実際に調整できる設定は、スレッド数です。Administration、Settings、Video Transcoding Settings の順に開きます。スレッド数が 0 の場合は、すべてのコアを使用します。2 コアのプランでは、1 本の動画だけで Web インターフェースが停止したように見えることがあります。Immich FAQ の推奨どおり、ここでは 1 または 2 に設定してください。トランスコードは遅くなりますが、システム全体への影響を抑えられます。
スワップスラッシングが発生したインポートがハングしたように見える理由
これは、最も頻繁に誤解される障害です。Immich のメモリが不足すると、2 つの結果が起こります。そのうち、障害のように見えるのは 1 つだけです。
スワップがない場合、kernel はプロセスを強制終了します。コンテナは数秒以内に再起動するため、ブラウザーから見るとジョブキューが停止した後、再開したように見えます。証拠は docker ps -a にあります。
docker ps -a --filter name=immich
docker inspect immich_machine_learning | grep -i oomkilled
sudo dmesg -T | grep -i -E 'out of memory|oom-kill'Exited (137) は、プロセスが signal 9 で強制終了されたことを意味します。137 は 128 に 9 を加えた値です。このステータスは、コンテナが停止している間だけ確認できます。再起動ポリシーによってコンテナが復帰すると、docker ps -a は再び Up を示します。また、ほかの Immich コンテナより uptime が大幅に短いことも手掛かりです。signal 9 だけでは、メモリの問題だとは断定できません。Docker は、通常の停止処理が timeout を超えた場合にも signal 9 を送るためです。OOMKilled の値が true であれば、メモリ不足によって強制終了されたことが確認できます。コンテナの再起動後は、dmesg の oom-kill 行を信頼すべき記録として確認します。
スワップがある場合、何も強制終了されず、エラーも発生しません。kernel はページをディスクへ移動し始め、インポートは桁違いに遅くなり、Web インターフェースは通常の timeout 内に応答しなくなります。すべてのコンテナは稼働しています。すべての health check が成功し続けることもあります。ハングしたように見えるため、この時点でサーバーを再起動する人がいます。しかし、これではキューの進捗が失われるだけで、状況は変わりません。
free -m
vmstat 1 5vmstat の si 列と so 列に 0 ではない値が継続的に表示される場合、マシンがスワップを継続的に読み書きしています。これがスラッシングの定義です。同時に、Swap で使用されている free -m 行の値も増加します。
2 GB または 4 GB のマシンでは、いずれにしてもスワップを追加してください。診断できる遅いインポートのほうが、復旧できない強制終了されたコンテナよりも対処しやすいためです。
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstabその後、原因を修正します。ジョブの同時実行数を 1 に下げる、machine learning コンテナに上限を設定する、またはそのコンテナをこのホストから移動します。スワップは、その対応を行うための時間を確保します。スワップだけでは解決になりません。
FAQ
Immich を 2 GB の VPS で実行できますか？
Immich が文書化している構成では実行できません。要件ページでは最小メモリとして 6 GB を設定しており、より小さい構成として挙げているのは、machine learning 機能を無効にした 4 GB の構成だけです。また、Docker のリソース制限を使用すると、データベースだけで少なくとも 2 GB が必要だと説明しています。immich-machine-learning service をコメントアウトし、ジョブの同時実行数を 1 に設定すれば動作する可能性はありますが、サポート対象外の妥協策です。import 中に停止される可能性が最も高い service は Postgres です。利用できるメモリが 2 GB しかない場合は、2 GB の swap file を追加してください。これにより、import の急増時にコンテナが停止される代わりに、サーバーの処理が遅くなります。プランを選ぶ場合は、4 GB から始めてください。
Immich の import がエラーメッセージなしで停止するのはなぜですか？
ブラウザーからは、2 つの異なる原因が同じように見えます。メモリ不足でコンテナが停止され、すでに再起動している場合は、docker ps -a で Up を確認できます。uptime が不自然に短くなっています（停止中に確認できた場合に限り Exited (137) も表示されます）。一方、ホストが swap を使用している場合は、すべてのコンテナが起動したままで、処理全体が単に非常に遅くなります。vmstat 1 5 で両者を区別できます。si 列と so 列に 0 以外の値が継続して表示される場合は、swap が発生しています。どちらの場合も、thumbnail 生成、face detection、smart search のジョブ同時実行数を下げてください。
Immich のログに表示される exit code 137 は何を意味しますか？
137 は 128 に signal 9 を加えた値なので、プロセスが SIGKILL で強制終了されたことを示します。Immich を実行するサーバーでは、通常はコンテナ自身のメモリ上限、またはホストのメモリ不足が原因です。ただし、code だけでは断定できません。Docker は、コンテナが timeout 内に停止しない場合にも SIGKILL を送信するためです。Linux では、timeout のデフォルト値は 10 秒です。docker inspect immich_machine_learning | grep -i oomkilled で確認してください。true の値は、kernel がメモリ不足を理由に停止したことを示します。続いて free -m と sudo dmesg -T | grep -i oom-kill により、コンテナの上限に達したのか、ホスト全体のメモリが不足したのかを判断できます。通常、最も大きなプロセスである machine learning container が停止対象になります。
Immich には写真 1 枚あたりどの程度のディスク容量が必要ですか？
元のファイル容量に 10 から 20 パーセントを加えて見積もってください。Immich の説明では、生成される thumbnail と transcoded video により、library の容量は平均で 10 から 20 パーセント増加します。大規模な library でも、database 自体は通常 1 から 3 GB です。総容量を実際に左右するのは video です。プランを選ぶ前に、自分のファイルの平均容量を測定してください。写真の枚数に単純な倍率を掛けて見積もるべきではありません。
Immich に GPU は必要ですか？
いいえ。Immich のすべての機能は CPU で動作します。GPU は machine learning container の model inference と video encoding を高速化しますが、どちらにも必須ではありません。ほとんどの VPS プランでは GPU を利用できません。CPU のみの hardware では、transcoding threads を 1 または 2 に設定し、buffalo_s face model を使用してください。最初の bulk import は夜間に実行するとよいでしょう。