Immich에 설정해야 할 메모리 제한은 얼마인가요?

Immich 메모리 제한을 보편적인 GB 숫자 하나로 설정하지 마세요. 호스트 수준의 RAM 목표와 컨테이너별 상한은 서로 다른 문제를 해결합니다. 호스트는 전체 스택을 지원해야 하고, 컨테이너 제한은 정상적인 Immich 작업을 중단시키지 않으면서 호스트를 보호해야 합니다.

처리된 라이브러리를 탐색할 때는 가볍게 보일 수 있지만, 콜드 머신러닝 시작, 대규모 가져오기, 썸네일 생성, 얼굴 분석 또는 동영상 작업에서는 훨씬 더 많은 메모리를 사용할 수 있습니다. 실제로 필요한 가장 무거운 작업을 측정하고, PostgreSQL과 운영 체제를 위한 여유 공간을 확보하세요. 반복적인 OOM 종료는 정상적인 스로틀링이 아니라 제한 설정 실패로 간주해야 합니다.

제한을 선택하기 전에 메모리 압박을 측정하세요

조용히 탐색하는 상태, 일반적인 일일 업로드, 계획된 백그라운드 작업 중 가장 무거운 상태 등 세 가지 상황에서 메모리를 기록하세요. 컨테이너 사용량, 호스트의 사용 가능한 메모리, 스왑 활동, OOM 이벤트, 작업이 계속 진행되는지 여부를 캡처합니다. Linux 메모리 회계에는 회수 가능성이 서로 다른 여러 종류의 메모리가 포함되므로, docker stats의 단일 피크만으로는 충분하지 않습니다.

유용한 Docker cgroup 메모리 분석은 원시 총량을 모두 똑같이 위험한 것으로 취급하지 않고 익명 메모리, 파일 기반 캐시, 슬랩을 구분합니다. 호스트 여유 공간이 충분한 안정적인 파일 캐시는 익명 메모리가 계속 증가하거나, 스왑 압박이 발생하거나, 동일한 Immich 작업 중 cgroup OOM 카운터가 증가하는 상황과 다릅니다.

반복해서 확인할 수 있는 최대 사용량을 식별하고, 그것이 대부분 회수 가능한 캐시인지 실제 작업 메모리인지 설명할 수 있다면 이 단계를 통과한 것입니다. 변경하지 않은 작업에서 사용량이 계속 증가하거나, 컨테이너가 반복적으로 OOM 종료되거나, 호스트가 심하게 스왑을 사용하기 시작하면 해당 실행 결과를 기준으로 용량을 정하지 말고 먼저 비정상적인 증가 원인을 진단하세요.

가장 무거운 유효한 Immich 작업을 기준으로 상한을 정하세요

제한을 적용한 후에도 지원해야 하는 작업을 선택하세요. 어떤 가정에서는 네 대의 휴대폰이 업로드하는 동안 Smart Search와 얼굴 관련 작업이 따라잡는 상황일 수 있고, 다른 가정에서는 대규모 초기 가져오기 후 일반적인 탐색이 될 수 있습니다. 측정하는 동안 데이터 세트, 모델, 동시성 설정 및 다른 컨테이너를 고정하여 제한이 명확한 서비스 약속을 반영하도록 하세요.

관찰된 회수 불가능한 최대 사용량보다 높게 하드 상한을 설정하되, 짧은 순간의 급증을 위한 측정 가능한 여유 공간을 남기고 PostgreSQL, 파일 시스템 캐시, 컨테이너 런타임 및 관련 없는 서비스에 필요한 호스트 메모리를 보존하세요. 로컬 AI 리소스 경고 신호에 관한 관련 ZimaSpace 체크리스트가 유용한 이유는 발열, 스왑, 갑작스러운 재시작이 Immich만 표시하는 그래프에서 놓칠 수 있는 호스트 수준의 압박을 드러내기 때문입니다. “컨테이너가 한 번 제한에 도달했다”는 사실을 RAM이 더 필요하다는 증거로 해석하지 마세요. 중요한 실패 기준은 동일한 유효한 작업이 심각하게 느려지거나, 작업을 잃거나, 지속적으로 스왑을 사용하거나, OOM 종료되는지 여부입니다. 반대로 Immich가 자체 cgroup이 경계에 도달하기 전에 데이터베이스나 호스트의 리소스를 고갈시킬 수 있다면 제한이 너무 느슨한 것입니다.

비정상적인 증가라면 제한을 높이기 전에 작업량을 줄이세요

제안한 상한이 특정 종류의 백그라운드 작업에서만 실패한다면, 상한을 높이기 전에 해당 작업의 동시성을 줄이거나 단계를 분리하세요. 머신러닝, 썸네일 생성, 동영상 처리 및 데이터베이스 작업은 서로 다른 메모리 사용 패턴을 보일 수 있습니다. 활성 배치를 줄이면 더 느리게 완료되더라도 가정용 인터페이스의 응답성과 호스트의 복구 가능성을 유지할 수 있습니다.

버전별 실패도 중요합니다. Immich v3.0.3 메모리 보고서에서는 잘못된 로캘 관련 조건으로 인해 머신러닝 워커의 메모리 사용량이 증가하다가 cgroup 제한에 도달해 OOM이 발생한 사례를 설명합니다. 이 사례는 일반적인 Immich RAM 사용량을 정의하지 않습니다. 설명할 수 없는 증가가 발생하면 호스트 예산을 영구적으로 늘리기 전에 소프트웨어 또는 구성 문제로 분기해 조사해야 한다는 점을 보여 줍니다.

동시성, 모델 또는 버전 변수 중 하나를 변경한 후 동일한 작업을 다시 실행하세요. 메모리 패턴과 원래 작업이 모두 예상한 방향으로 개선된 경우에만 변경 사항을 유지하세요. 메모리가 안정적인 정점에 도달하지 않고 계속 증가한다면 로그와 버전 정보를 보존하고, 하드 제한을 계속 더 큰 숫자로 바꾸는 대신 문제를 상위 단계로 전달하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

콜드 재시작과 사용량이 많은 주기 후에 제한을 검증하세요

호스트를 재시작하여 캐시와 모델 상주 상태가 알려진 콜드 상태에서 시작되도록 하세요. 일반적인 로그인 및 탐색 확인을 수행한 다음, 대표적인 업로드와 백그라운드 작업을 실행하세요. 익명 메모리 최대 사용량, 캐시, 스왑, OOM 카운터, 데이터베이스 응답, 대기열 처리 시간 및 다른 중요한 컨테이너의 응답 상태를 기록하세요.

통과하는 제한은 콜드 시작과 가장 바쁜 일반 주기 모두에서 OOM 종료, 지속적인 스왑 폭주, 반복적인 컨테이너 재시작 또는 처리가 멈춘 대기열 없이 작동해야 합니다. 또한 Immich가 바쁜 상태에서도 데이터베이스 덤프나 관리자 로그인 같은 복구 작업을 수행할 수 있도록 충분한 호스트 여유 공간을 남겨야 합니다.

정의한 모든 가정용 작업은 통과하지만 인위적인 스트레스 테스트만 실패한다면, 필요하지 않은 상황을 위해 RAM을 구매하는 대신 허용된 경계를 문서화하세요.

실제 작업이 호스트를 고갈시키지 않고는 통과할 수 없다면 동시성을 낮추고, 머신러닝을 분리하고, 메모리를 추가하거나, 경쟁 서비스들을 다른 곳으로 옮기세요. 그런 다음 새 제한이 안전하다고 선언하기 전에 동일한 검증을 반복하세요.