여러 컨테이너에서 동시 실행할 때 Immich 데이터베이스 연결을 최적화하는 방법

모든 Immich 프로세스와 기타 PostgreSQL 클라이언트의 전체 세션 수요를 측정하여 Immich 데이터베이스 연결을 최적화하세요. 먼저 max_connections를 늘리는 방식은 피해야 합니다. 데이터베이스에는 실제 워크로드와 관리 작업을 위한 여유 공간을 감당할 만큼의 세션이 필요하지만, 과도한 동시성은 쿼리를 더 빠르게 만들지 못한 채 메모리 사용량과 경합만 증가시킬 수 있습니다.

여러 컨테이너가 실행되는 홈 서버에서는 일반적인 사용 중과 여러 서비스가 동시에 시작되는 상황에서 활성, 유휴, 대기 중인 연결을 쿼리 지연 시간, CPU, 메모리, 스토리지 지연 시간과 함께 기록하세요. Immich 컨테이너 하나만 보면 연결 수가 많지 않아 보여도 “클라이언트가 너무 많습니다” 오류는 전체 설정, 다른 서비스 또는 반복적인 재시작 폭주로 인해 발생할 수 있습니다.

제한을 변경하기 전에 모든 PostgreSQL 클라이언트를 파악하세요

각 Immich 서버 프로세스 또는 복제본, 마이그레이션/유지 관리 작업, 백업 작업, 모니터링 도구, 그리고 동일한 PostgreSQL 인스턴스에 연결하는 관련 없는 애플리케이션을 나열하세요. 가능하면 각각에 별도의 데이터베이스 사용자를 할당하여 pg_stat_activity에서 어떤 클라이언트가 세션을 점유하는지 확인할 수 있도록 하세요. 현재 max_connections 값을 기록하고, 장애 대응을 위한 관리자용 접속 경로를 하나 유지하세요.

Immich의 “클라이언트가 너무 많습니다” 토론에는 해당 릴리스에서 Immich가 기본 풀 크기 10을 사용했다는 프로젝트 댓글이 포함되어 있습니다. 별도의 2026년 토론에서는 여러 Immich 워커가 각각 하나의 풀을 유지할 수 있다고 설명합니다. 이러한 수치는 버전별 구현에 대한 참고 정보로만 보고, 향후 릴리스에 무작정 곱해서 적용할 숫자로 사용하지 마세요. Immich가 유휴 상태인데도 데이터베이스가 이미 연결 한도에 가까우면, Immich를 조정하기 전에 해당 세션의 소유자를 확인하세요. 활성 세션은 적은데 쿼리가 느리다면 연결 수는 스토리지 또는 쿼리 지연 시간의 증상일 수 있으며, 주요 병목이 아닐 수도 있습니다.

측정한 동시성을 바탕으로 연결 예산을 수립하세요

데이터베이스 관리, 백업/복구 도구, 마이그레이션, 모니터링을 위한 세션을 먼저 확보하세요.

그런 다음 동시에 실행되는 Immich 프로세스 수와 기타 애플리케이션에 남은 애플리케이션 연결을 배분하세요. 목표는 일반적인 작업이 불필요하게 대기하지 않을 만큼 충분히 큰 풀이면서도, 데이터베이스가 효율적으로 실행할 수 있는 범위를 넘지 않도록 하는 것입니다.

PostgreSQL 연결 풀 크기 산정 분석에서는 일반적인 수요를 감당할 만큼 충분하면서도 가능한 한 작게 유지하는 풀을 이상적인 풀로 설명합니다. 백엔드 세션 수가 적을수록 경합이 줄어들기 때문입니다. 다른 워크로드의 웹 서버 풀 크기를 그대로 복사하지 말고, 관찰한 Immich 수요에 이 원칙을 적용하세요.

Immich 릴리스에서 지원되는 풀 크기 제어 기능을 제공하지 않는다면, 목표 연결 수를 맞추기 위해 내부 구현을 수정하지 마세요. 애플리케이션 복제본 수, 관련 없는 클라이언트, 재시작 시점, 백업 중첩, 데이터베이스 용량처럼 제어할 수 있는 항목을 조정하세요. 버전이 변경되면 지원되는 설정을 다시 확인하세요.

세션을 늘리기 전에 연결 생성과 데이터베이스 대기를 줄이세요

Immich, 분석 작업, 백업 작업 및 기타 애플리케이션이 모두 동시에 재연결하거나 마이그레이션을 수행하지 않도록 컨테이너 시작을 분산하세요. PostgreSQL을 사용할 수 있을 때까지 대기하는 상태 확인/준비 상태 확인을 사용하되, 데이터베이스가 아직 복구 중일 때 연결 폭주를 일으키는 짧은 재시도 간격은 피하세요.

ZimaSpace의 외부 Immich 데이터베이스 안전성 가이드는 중요한 기준을 제시합니다. PostgreSQL을 기본 스택에서 분리하면 버전, 확장 기능, 권한, 백업 및 롤백에 대한 책임이 명확해집니다. 느린 쿼리나 포화된 스토리지를 단순히 감추기 위해 연결 프록시나 추가 데이터베이스 호스트를 도입해서는 안 됩니다.

유휴 세션이 많고 애플리케이션 수가 실제로 많은 경우, 일부 PostgreSQL 아키텍처에서는 연결 풀러가 백엔드 세션 수를 줄일 수 있습니다. 그러나 정확한 Immich 버전, 마이그레이션, 트랜잭션 의미, 준비된 문장의 동작을 테스트한 후에만 적용하세요. 풀링은 폭주하는 클라이언트나 과부하된 데이터베이스를 바로잡는 대안이 아닙니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

동시 업로드, 검색, 작업 및 재시작으로 검증하세요

대표적인 모바일 업로드, 오래된 항목에 대한 검색 또는 탐색 작업, 일반적인 백그라운드 작업 조합을 실행하고 예상되는 다른 컨테이너도 활성화하여 반복 가능한 피크 상황을 만드세요. 사용자 및 상태별 연결 수, 연결 획득 또는 요청 오류, 쿼리 지연 시간, 데이터베이스 CPU, 메모리 및 디스크 지연 시간을 기록하세요. 그런 다음 한 가지를 변경한 후 다시 반복하세요.

통과하는 설정은 관리 작업을 위한 여유 공간을 유지하면서 세션 수를 장애 한도 아래로 유지하고, “클라이언트가 너무 많습니다” 오류를 피하며, 가정 내 목표 범위의 쿼리 지연 시간을 유지하고, 피크 이후 대기열이 소진되도록 해야 합니다. 데이터베이스에 여전히 CPU, 메모리 및 I/O 용량이 남아 있는데도 요청이 실제로 세션을 기다리는 경우에만 연결 수를 늘리는 것이 타당합니다.

가장 큰 연결 폭주를 테스트하기 위해 먼저 애플리케이션 스택을 재시작한 다음 호스트를 한 번 재시작하세요. 시작 중에만 오류가 발생한다면 영구적인 연결 한도를 높이지 말고 시작 순서와 재시도 동작을 수정하세요. 시간이 지나면서 세션이 누적된다면 해당 세션을 소유한 사용자와 쿼리를 수집하고, 버전 및 연결 상태 증거와 함께 이러한 누수 패턴을 조사하도록 에스컬레이션하세요.