Immich 서버 권장 RAM 및 디스크 용량 가이드

Immich는 어느 정도의 RAM을 필요로 합니까?

Immich는 문서화된 최소 사양으로 6 GB의 RAM(임의 접근 메모리)을 요구하며, 권장 사양은 8 GB입니다. CPU 코어는 최소 2개, 원활한 설치를 위해서는 4개를 권장합니다. Immich는 단일 애플리케이션이 아니라 4개의 컨테이너로 구성되므로, 이 수치는 전체 스택을 포함합니다. 이미 가져오기가 완료된 라이브러리를 탐색하는 것은 리소스 소모가 적습니다. 메모리는 주로 가져오기 작업에 사용되며, 대부분은 사용자가 끌 수 있는 특정 컨테이너에서 소비됩니다.

[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

위 수치는 2026년 8월 기준 Immich 요구 사항 페이지에 게시된 공식 수치입니다. 이는 권장 사양이며, 소프트웨어 실행 시점에 수행하는 하드웨어 검사 항목은 아닙니다. Immich는 이보다 적은 메모리에서도 시작할 수 있습니다. 서버 사양이 낮을 경우 영향을 받는 것은 백그라운드 작업의 완료 여부와 메모리가 부족할 때의 가져오기 작업 동작입니다.

실질적인 하드웨어 제한 사항이 하나 있습니다. Immich 버전 3 이상은 amd64 호스트에서 x86-64-v2 CPU를 필요로 하며, 이는 대략 2012년 이후 판매된 대부분의 프로세서를 포함합니다. 더 오래된 하드웨어에서는 컨테이너가 느리게 동작하는 것이 아니라 아예 시작되지 않습니다.

아직 설치 전이라면 Docker Compose를 이용한 전체 Immich 설치 가이드를 먼저 확인한 뒤, 이 내용을 참고하여 서버 규모를 결정하십시오.

메모리 사용처: 4개의 컨테이너

공식 Compose 파일은 4개의 서비스를 시작합니다. 각 서비스는 서로 다른 메모리 형태를 가지므로, 전체 합계만으로는 유용한 정보를 파악하기 어렵습니다.

immich-server는 웹 인터페이스와 API를 제공하며, 백그라운드 작업 워커도 실행합니다. 이 단일 컨테이너 안에는 2개의 워커가 상주합니다. api는 브라우저와 모바일 앱의 요청에 응답합니다. microservices은 썸네일 생성 및 비디오 인코딩을 포함한 큐를 처리합니다. IMMICH_WORKERS_INCLUDE 및 IMMICH_WORKERS_EXCLUDE 변수는 이 두 작업을 별도의 컨테이너로 분리합니다. 이를 통해 사진을 제공하는 절반의 성능을 제한하지 않으면서, 부하가 많은 나머지 절반에만 별도의 메모리 제한을 설정할 수 있습니다.

database는 VectorChord 확장 기능이 내장된 PostgreSQL 14 이미지입니다. 이 컨테이너는 모든 메타데이터와 자산당 하나의 검색 벡터를 보관합니다. Immich 문서에서는 이 서비스에 대해 스택 내 유일한 명시적 최소 사양을 제시합니다. Docker 리소스 제한을 적용할 경우 데이터베이스는 최소 2 GB의 메모리가 필요합니다. 또한 같은 문서에서 데이터베이스는 반드시 로컬 SSD 스토리지에 위치해야 하며 네트워크 공유 드라이브를 사용해서는 안 된다고 명시합니다. 벡터 및 인덱스 조회는 작은 단위의 무작위 읽기 작업이므로, 네트워크 볼륨을 사용하면 매 작업마다 왕복 지연 시간이 발생하기 때문입니다. 요금제 선택 시 이 점이 중요하다면, VPS의 NVMe와 SATA SSD 스토리지 간의 차이가 이 스택의 다른 어떤 부분보다 더 큰 영향을 미칩니다.

redis은 Valkey 이미지를 실행하며 작업 큐를 보관합니다. 사진 데이터가 아닌 작업 기록을 저장하므로 4개의 컨테이너 중 가장 메모리 사용량이 적습니다.

immich-machine-learning은 요금제 규모를 결정하는 서비스입니다. 스마트 검색, 얼굴 인식, 텍스트 인식을 위한 모델을 로드하며, 로드된 모델은 메모리에 상주합니다. MACHINE_LEARNING_MODEL_TTL의 기본값은 300이므로, 5분 동안 요청이 없으면 모델이 메모리에서 해제되고 다음 요청 시 /cache 볼륨에서 다시 읽어옵니다. 대량 가져오기(bulk import) 중에는 5분 이상의 공백이 발생하지 않으므로, 첫 번째 자산부터 마지막 자산까지 모델이 계속 로드된 상태로 유지됩니다.

가져오기 시 발생하는 변화

유휴 상태의 Immich는 조용합니다. 서버가 가장 취약해지는 시점은 가져오기를 수행할 때입니다. 하나의 에셋을 업로드하면 일련의 작업 큐가 생성되고, 여러 큐가 동시에 실행되기 때문입니다.

메타데이터 추출은 파일 헤더만 읽으므로 가볍습니다. 썸네일 생성은 더 무거운 작업입니다. Immich는 에셋 하나당 흐릿한 thumbhash 플레이스홀더, WebP 미리보기, JPEG 썸네일 등 세 가지 썸네일 결과물을 생성하며, 감지된 얼굴마다 썸네일이 하나씩 추가됩니다. 각 작업은 이미지를 디코딩하며, 작업 동시성(concurrency) 설정에 따라 한 번에 처리할 디코딩 개수가 결정됩니다. 동시성은 개별 작업의 비용을 서버 전체의 부하로 증폭시키는 배율기 역할을 합니다. 이것이 바로 Immich FAQ에서 사양이 낮은 기기일 때 가장 먼저 낮춰야 할 설정으로 동시성을 꼽는 이유입니다. Administration, Settings, Job Settings에서 무거운 큐의 동시성을 1로 설정하십시오.

비디오 에셋은 트랜스코딩 과정을 추가합니다. 각 트랜스코딩 작업은 별도의 메모리를 사용하는 독립적인 FFmpeg 프로세스이며, 허용된 모든 CPU 스레드를 사용합니다.

스마트 검색은 모든 새 에셋을 머신러닝 컨테이너로 보내 하나의 임베딩 벡터를 계산합니다. 얼굴 감지 기능은 동일한 이미지에 대해 두 번째 모델을 실행합니다. 기존 사진 라이브러리를 처음 가져올 때는 이 두 큐가 보유한 모든 에셋에 대해 수 시간 동안 실행됩니다. 이는 전체 설치 환경에서 메모리 사용량이 가장 극심한 순간이며, 최초 1회만 발생합니다.

얼굴 및 객체 인식에 가장 많은 RAM이 필요한 이유

얼굴 처리는 두 가지 작업으로 나뉩니다. 얼굴 감지는 머신러닝 컨테이너에서 모델을 실행하여 얼굴 영역을 찾아냅니다. 얼굴 인식은 감지된 결과를 사람별로 그룹화하며, 이 단계에서 Postgres의 벡터 인덱스를 조회합니다. 따라서 라이브러리가 크면 두 서비스에 차례로 부하가 발생합니다. 감지가 실행될 때는 모델 컨테이너에, 그룹화가 실행될 때는 데이터베이스에 부하가 걸립니다.

머신러닝 컨테이너의 메모리 점유율을 결정하는 설정은 네 가지입니다.

• 얼굴 모델. Immich는 기본값으로 buffalo_l를 제공하며, FAQ에서는 소규모 서버의 경우 buffalo_s 사용을 권장합니다. 이 모델은 크기가 작아 메모리를 덜 차지하고 더 빠르게 실행되지만, 작거나 측면을 향한 얼굴에 대한 정확도는 떨어질 수 있습니다.
• 워커 수. MACHINE_LEARNING_WORKERS의 기본값은 1입니다. 각 워커는 별도의 프로세스로서 모델의 복사본을 각각 메모리에 로드하므로, 이 값을 2로 높이면 상주 모델 메모리 사용량이 대략 두 배로 늘어납니다. 여유 RAM이 충분하지 않다면 1로 유지하십시오.
• 배치 크기. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION은 한 번에 처리할 얼굴 수를 제한합니다. 배치는 한꺼번에 메모리에 적재되므로, 40명의 얼굴이 포함된 단체 사진은 인물 사진보다 더 많은 메모리를 소모합니다.
• 실행할 모델 유형. 스마트 검색, 얼굴 감지, 텍스트 인식은 각각 고유한 모델을 로드합니다. Administration, Settings, Machine Learning Settings에서 사용하지 않는 기능을 끄면, 가져오기 작업 사이가 아니라 상시적으로 해당 모델의 메모리 점유를 해제할 수 있습니다.

또한 MACHINE_LEARNING_MODEL_ARENA 설정이 있습니다. 이는 파편화를 방지하기 위해 CPU 메모리를 미리 할당하는 기능으로 기본 활성화되어 있습니다. 이 설정은 가장 마지막에 변경하십시오. 효과는 하부 메모리 할당자에 따라 달라지므로, 변경 전후의 docker stats를 모니터링하는 것이 유일한 객관적인 판단 방법입니다.

세 가지 작업 프로필: 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": "machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 1280,
    "ml_limit_mb": 1024,
    "redis_limit_mb": 192,
    "notes": "machine learning on, job concurrency 1, buffalo_s"
  },
  {
    "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에 입력할 제한 값으로 이해해야 합니다. 제한은 상한선일 뿐입니다. 메모리를 미리 점유하거나 서비스를 작게 만드는 것이 아닙니다. 시스템 메모리가 부족할 때 커널이 어떤 서비스를 종료할지 결정하는 기준이며, 커널의 자체 점수 산정 방식에 맡기는 것보다 사용자가 직접 결정하는 것이 좋습니다.

2 GB 서버: 머신러닝 컨테이너 제거

2 GB는 문서화된 최소 요구 사양인 6 GB 미만이므로, 이는 타협안이며 그에 따른 제약이 있음을 인지해야 합니다. docker-compose.yml 파일에서 immich-machine-learning 서비스 전체를 주석 처리하거나, 서비스를 실행한 상태에서 Administration, Settings, Machine Learning Settings의 모든 모델을 비활성화하십시오. 모델을 비활성화해도 Python 프로세스가 상주하므로 컨테이너를 제거하는 것이 더 확실한 방법입니다.

이 경우 업로드, 앨범, 공유, 모바일 백업, 썸네일, 날짜·장소·파일명 기반 검색은 유지됩니다. 하지만 설명 기반 검색, 얼굴 자동 그룹화, 이미지 내 텍스트 인식 기능은 사용할 수 없습니다.

네 가지 제한 값을 합치면 약 1.7 GB가 되어 호스트에 약 300 MB 정도의 여유가 남습니다. 데이터베이스에 할당된 768 MB는 문서화된 최소 권장 사양인 2 GB보다 낮다는 점에 유의하십시오. 이것이 바로 2 GB 환경에서 불가피한 타협이며, Postgres가 가장 먼저 종료될 가능성이 높은 서비스인 이유입니다.

가장 먼저 문제가 발생하는 부분은 탐색이 아니라 가져오기(import) 작업입니다. 수만 장 규모의 사진 라이브러리는 일단 가져오기가 완료되면 페이지 제공 시 메타데이터 쿼리와 파일 읽기만 수행하므로 탐색은 원활합니다. 하지만 동일한 서버에서 영상 위주의 가져오기를 수행하면 트랜스코딩과 썸네일 큐가 동시에 메모리를 점유하려 하므로 스왑(swap)이 발생합니다. 모든 무거운 작업 큐의 동시성(concurrency)을 1로 설정하고 스왑 파일을 추가하십시오.

4 GB 서버: 머신러닝 활성화, 작업 동시성 1로 제한

4 GB는 얼굴 및 객체 인식 기능을 켜기에 적합한 최소 사양입니다. 머신러닝 컨테이너를 0 MB로 제한하고, 얼굴 인식을 buffalo_s로 설정하며, 썸네일 생성, 얼굴 탐지, 스마트 검색의 작업 동시성을 1로 설정하십시오.

기존 라이브러리에 대한 첫 번째 분석 작업은 수 시간, 대규모 라이브러리의 경우 하루 이상 걸릴 수 있습니다. 이는 메모리가 아닌 CPU 성능의 한계이므로 RAM을 늘려도 단축되지 않습니다.

이 환경에서 가장 먼저 문제가 발생하는 지점은 초기 대량 분석 중의 머신러닝 컨테이너입니다. 제한을 두지 않으면 트랜스코딩 작업이 커질 때 머신러닝 컨테이너도 함께 커지며, 커널이 둘 중 더 큰 프로세스를 종료시킵니다. 이때 docker ps -a에서 Exited (137) 오류를 확인하게 되며, 컨테이너가 재시작되면서 작업 큐는 이전보다 더 뒤처지게 됩니다.

8 GB 서버: 문서 권장 사양

8 GB와 4 코어 구성은 Immich의 권장 사양과 일치하며, 스마트 검색, 얼굴 탐지, 텍스트 인식, 트랜스코딩 등 모든 기능을 기본 동시성 설정으로 실행할 수 있습니다. 10만 개 이상의 에셋이 포함된 라이브러리도 원활하게 처리됩니다. 이때는 메모리보다 디스크 속도가 병목이 되는데, 데이터베이스가 벡터 인덱스와 메타데이터 쿼리를 지속적으로 처리하기 때문입니다.

그럼에도 제한 값을 설정하는 것이 좋습니다. 여유가 있는 서버라도 제한을 설정하면 특정 큐가 폭주하여 데이터베이스까지 함께 다운되는 상황을 방지할 수 있습니다. 더 낮은 사양의 옵션과 비용을 비교해 본다면, 메모리 계층별 실제 VPS 비용을 고려할 때 8 GB 플랜이 설정을 조정하는 수고를 덜 수 있는 가장 경제적인 선택인 경우가 많습니다.

Compose에서 서비스별 메모리 제한 설정 방법

이 작업을 위해 docker-compose.yml 파일을 수정하지 마십시오. 해당 파일은 wget을 사용하여 업그레이드할 때마다 교체됩니다. 제한 설정은 옆에 있는 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: 1280M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

이제 docker stats를 실행하면 호스트의 전체 메모리 대신 설정한 상한값이 MEM USAGE / LIMIT 열에 표시되어야 합니다. 제한 열에 여전히 호스트의 전체 크기가 표시된다면, 오버라이드 파일이 적용되지 않은 것입니다. 파일 이름을 확인하고 docker compose config을 실행하여 병합된 결과를 확인하십시오.

제한값이 너무 낮으면 느린 서비스가 완전히 중단될 수 있으므로, 컨테이너가 반복적으로 재시작된다면 값을 높여야 합니다. 이 메커니즘에 대한 자세한 내용은 Docker Compose에서 서비스별 메모리 제한 설정하기에서 확인할 수 있으며, 여기에는 Compose v2에서 deploy가 Swarm 외부에서도 작동하는 이유가 포함되어 있습니다.

머신러닝 컨테이너를 끄거나 이동하는 방법

소규모 서버에서 이 컨테이너를 다른 곳으로 옮기는 것은 성능 향상을 위해 취할 수 있는 가장 큰 조치입니다. Immich는 다른 머신에서 해당 컨테이너를 실행하는 것을 지원합니다. 저녁에만 켜두는 데스크톱과 같은 두 번째 호스트에 다음 파일을 생성하십시오.

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

그런 다음 웹 인터페이스의 Administration, Settings, Machine Learning Settings로 이동하여 Add URL을 클릭하고 http://<host>:3003을 입력하십시오. Immich 문서에 따르면 두 호스트 간의 버전 불일치는 버그와 불안정성을 유발하므로 양쪽 호스트의 버전을 동일하게 유지해야 합니다.

해당 포트는 사진 데이터를 암호화되지 않은 상태로 다른 머신으로 전송하므로, 사설 네트워크 내에서 사용하거나 두 호스트 간의 WireGuard 터널을 통해 실행하십시오. 3003 포트를 인터넷에 절대 노출하지 마십시오.

상주 모델 컨테이너를 실행하는 것 자체가 문제라면, 계획을 확정하기 전에 PhotoPrism과 Immich가 유휴 상태에서 무엇을 실행하는지 비교해 보는 것도 타당한 이유가 됩니다.

Immich 라이브러리에는 디스크 공간이 얼마나 필요한가?

네 가지 요소가 각기 다른 비율로 증가하기 때문에 단일 배수를 적용할 수 없습니다. 사진 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에서 이 볼륨을 공간 점유의 원인으로 명시하는 이유가 바로 이것입니다.

다섯 개의 행을 합치면 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은 원본으로부터 재생성할 수 없으므로 이 폴더들만이 대체 불가능한 데이터입니다.

두 가지 사실이 사용자들을 놀라게 합니다. 삭제된 자산은 먼저 휴지통으로 이동하며 휴지통을 비우기 전까지는 공간을 계속 차지하므로, 대규모 정리를 수행한 당일에는 여유 공간이 늘어나지 않습니다. 또한 데이터베이스 덤프는 메타데이터일 뿐이므로 원본 파일 없이는 아무런 가치가 없습니다:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

이와 함께 원본 파일의 파일 수준 복사본을 서버 외부의 다른 곳에 보관하십시오. 이것이 바로 VPS에서 외부 저장소로 restic 백업을 수행하는 이유입니다.

트랜스코딩은 RAM이 아닌 CPU를 사용합니다

RAM을 추가해도 트랜스코딩 속도는 빨라지지 않습니다. Immich는 FFmpeg를 사용하여 트랜스코딩을 수행하며, 일반적인 VPS 환경에서는 모든 프레임이 CPU에 의해 디코딩 및 인코딩됩니다. 하드웨어 가속을 사용할 수 있는 경우에도 Immich 문서에 따르면 인코딩만 가속되므로, 디코딩과 톤 매핑은 여전히 CPU가 소프트웨어 방식으로 처리합니다.

하드웨어 가속을 사용하려면 추가적인 hwaccel.transcoding.yml Compose 파일과 함께 NVENC, Quick Sync, RKMPP 또는 VAAPI를 사용하여 장치를 패스스루(pass-through)해야 합니다. 대부분의 VPS 플랜은 이러한 기능을 제공하지 않으므로 CPU 성능을 기준으로 계획을 세워야 합니다.

실질적인 설정 항목은 스레드 수입니다. Administration, Settings, Video Transcoding Settings에서 스레드 값을 0으로 설정하면 모든 코어를 사용하게 되며, 이로 인해 2코어 플랜에서는 영상 하나만 처리해도 웹 인터페이스가 멈출 수 있습니다. Immich FAQ의 권장 사항에 따라 이 값을 1 또는 2로 설정하면, 트랜스코딩 속도는 느려지더라도 시스템 전체가 마비되는 현상을 방지할 수 있습니다.

스왑 스래싱 현상이 멈춤 현상처럼 보이는 이유

이는 사용자가 가장 흔하게 오해하는 장애 유형입니다. Immich가 메모리 부족 상태에 빠지면 두 가지 결과가 나타나며, 그중 하나만 장애로 인식됩니다.

스왑이 없으면 커널이 프로세스를 강제 종료합니다. 컨테이너는 수 초 내에 재시작되므로, 브라우저에서 보면 작업 대기열이 잠시 멈췄다가 다시 진행되는 것처럼 보입니다. 관련 증거는 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)은 프로세스가 시그널 9에 의해 종료되었음을 의미합니다. 137은 128에 9를 더한 값입니다. OOMKilled 값이 true인 것은 충돌이 아니라 메모리 부족으로 인해 종료되었음을 확증합니다.

스왑이 있으면 아무것도 종료되지 않으며 오류도 발생하지 않습니다. 커널이 메모리 페이지를 디스크로 옮기기 시작하면서 가져오기 속도가 10배 이상 느려지고, 웹 인터페이스는 일반적인 타임아웃 시간 내에 응답하지 않게 됩니다. 모든 컨테이너는 실행 중이며, 모든 상태 확인(health check)도 통과할 수 있습니다. 이 상태는 멈춤 현상처럼 보이며, 사용자는 이 시점에서 서버를 재부팅하게 되는데, 이는 작업 대기열의 진행 상황을 초기화할 뿐 근본적인 문제를 해결하지 못합니다.

free -m
vmstat 1 5

vmstat의 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

그 후 원인을 해결하십시오. 작업 동시성(job concurrency)을 1로 낮추거나, 머신 러닝 컨테이너의 자원을 제한하거나, 해당 컨테이너를 다른 호스트로 옮기십시오. 스왑은 이를 수행할 시간을 벌어줄 뿐, 그 자체로 해결책은 아닙니다.

FAQ

2 GB VPS에서 Immich를 실행할 수 있습니까?

네, docker-compose.yml에서 immich-machine-learning 서비스를 주석 처리하고 작업 동시성을 1로 설정하면 가능합니다. 이는 문서화된 최소 요구 사양인 6 GB 미만이므로, 알려진 제약 사항을 감수해야 합니다. 업로드, 앨범, 공유, 모바일 백업, 날짜·장소·파일명 기반 검색은 유지됩니다. 설명 기반 검색, 인물별 자동 그룹화, 이미지 내 텍스트 인식 기능은 사용할 수 없습니다. 2 GB 스왑 파일을 추가하여 가져오기 작업 시 부하가 급증해도 컨테이너가 종료되지 않고 서버 속도가 느려지도록 조치하십시오.

Immich 가져오기가 오류 메시지 없이 중단되는 이유는 무엇입니까?

브라우저에서는 두 가지 원인이 동일하게 보입니다. 메모리 부족으로 컨테이너가 종료된 경우 docker ps -a에서 Exited (137) 상태가 확인되며 컨테이너가 이미 재시작된 상태입니다. 호스트가 스왑을 사용 중인 경우 모든 컨테이너는 실행 중이지만 전체적으로 매우 느려집니다. vmstat 1 5 명령으로 이를 구분할 수 있습니다. si 및 so 열의 값이 0이 아닌 상태로 지속되면 스왑이 발생하고 있는 것입니다. 어떤 경우든 썸네일 생성, 얼굴 인식, 스마트 검색의 작업 동시성을 낮추십시오.

Immich 로그의 종료 코드 137은 무엇을 의미합니까?

137은 128에 신호 9를 더한 값으로, 프로세스가 SIGKILL로 종료되었음을 의미합니다. 실제로는 컨테이너 자체 제한이나 호스트 메모리 부족으로 인해 메모리 한계에 도달했음을 뜻합니다. docker inspect immich_machine_learning | grep -i oomkilled로 확인하십시오. true 값은 커널이 메모리 부족으로 프로세스를 종료했음을 나타내며, free -m 및 sudo dmesg -T | grep -i oom-kill를 통해 컨테이너 제한인지 호스트 전체의 문제인지 파악할 수 있습니다. 머신 러닝 컨테이너는 일반적으로 가장 큰 프로세스이므로 가장 자주 종료되는 대상입니다.

Immich는 사진당 어느 정도의 디스크 공간이 필요합니까?

원본 파일 용량에 10에서 20퍼센트를 추가로 예산에 반영하십시오. Immich 문서에 따르면 생성된 썸네일과 트랜스코딩된 비디오는 라이브러리 크기를 평균 10에서 20퍼센트 증가시키며, 데이터베이스 자체는 대규모 라이브러리라도 보통 1에서 3 GB를 차지합니다. 전체 용량은 비디오 파일이 결정하므로, 사진 개수에 배수를 적용하기보다 본인의 평균 파일 크기를 측정하여 요금제를 선택하십시오.

Immich를 위해 GPU가 필요합니까?

아니요. Immich의 모든 구성 요소는 CPU에서 실행됩니다. 그래픽 카드는 머신 러닝 컨테이너의 모델 추론과 비디오 인코딩 속도를 높여주지만, 필수 사항은 아닙니다. 대부분의 VPS 요금제는 GPU를 제공하지 않습니다. CPU만 사용하는 환경에서는 트랜스코딩 스레드를 1 또는 2로 설정하고, buffalo_s 얼굴 인식 모델을 사용하며, 첫 대량 가져오기는 밤새 실행되도록 두십시오.