재부팅 후 Immich 시작 시간을 줄이는 방법

홈 서버가 재부팅된 후에만 Immich를 사용할 수 있게 되기까지 시간이 오래 걸린다면, 애플리케이션 자체를 “더 빠르게” 만들기 전에 어떤 종속 요소가 가장 늦게 준비되는지 측정하세요.

재부팅하면 스토리지 마운트, PostgreSQL, 네트워크 경로, DNS 또는 기타 서비스가 일반적인 Immich 재시작 때와 다른 순서로 준비될 수 있습니다. 유용한 지표는 Docker가 컨테이너가 시작되었다고 표시한 시점이 아니라, 호스트 부팅부터 데이터베이스가 실제 요청을 수락하고, 필요한 스토리지가 마운트되며, Immich가 종속 요소 재시도를 멈추고, 클라이언트에서 타임라인을 로드할 수 있을 때까지 걸리는 시간입니다. 이 순서를 한 번 기록한 다음 실제 대기 또는 재시도 루프를 제거하세요.

변경하기 전에 부팅 타임라인 측정하기

유지 관리 시간에 재부팅하고 다음 네 시점에 타임스탬프를 기록하세요. 호스트에 연결할 수 있게 된 시점, Immich 관련 스토리지가 마운트된 시점, 데이터베이스가 정상 상태가 된 시점, 클라이언트에서 Immich를 사용할 수 있게 된 시점입니다. 또한 컨테이너 시작 시간, 상태 검사 결과, 재시작 횟수, 각 서비스의 첫 번째 유용한 로그 줄도 기록하세요. 이렇게 하면 “시작이 느리게 느껴진다”는 상태를 구체적인 지연 시간으로 바꿀 수 있습니다.

호스트가 완전히 실행된 후 수행한 일반적인 스택 재시작 결과와 비교하세요. 이후 Immich를 재시작하면 빠르지만 부팅 시에만 느리다면, 병목은 애플리케이션 외부의 실행 순서 또는 준비 상태 종속성일 가능성이 높습니다. 두 경우 모두 똑같이 느리다면 데이터베이스 작업, 스토리지 지연 시간, 마이그레이션 또는 CPU 사용량을 조사하세요.

모든 계층을 한 번에 최적화하지 마세요. 이 단계의 목표는 컨테이너 시작 시간에 비해 준비가 늦어지거나 Immich가 반복적으로 재시도하게 만드는 첫 번째 구성 요소를 찾아내는 것입니다.

Immich 시작 전에 스토리지가 준비되었는지 확인하기

Immich 서비스가 시작되기 전에 모든 바인드 마운트와 네트워크 기반 경로가 존재하고 예상 데이터가 들어 있는지 확인하세요. 실제 디스크나 NAS 공유가 아직 사용할 수 없는데 마운트 지점이 빈 로컬 디렉터리로 존재할 수 있습니다. 이 경우 애플리케이션이 잘못된 파일 시스템을 기준으로 시작할 수 있습니다.

데이터베이스나 미디어가 부팅 중 늦게 나타나는 스토리지에 있다면, 호스트 수준에서 해당 마운트에 서비스가 의존하도록 설정하거나 마운트가 실제로 준비될 때까지 스택 시작을 지연하세요. 테스트에서는 디렉터리 이름이 존재하는지만 확인하지 말고, 실제로 마운트된 파일 시스템이나 알려진 식별 파일을 확인해야 합니다.

스토리지 준비 상태를 조정한 후 다시 재부팅하고 동일한 타임스탬프를 비교하세요. 성공적인 변경이라면 정상 상태의 Immich 설정을 바꾸지 않고도 재시도나 빈 경로 동작이 사라져야 합니다. 데이터베이스보다 스토리지가 이미 훨씬 먼저 준비되어 있었다면 임의의 대기 타이머를 추가하지 말고 종속성 순서로 넘어가세요.

단순히 실행 중인지가 아니라 데이터베이스가 정상 상태인지 확인하기

특히 비정상 종료, 스토리지 지연, 초기화 또는 복구 후에는 PostgreSQL 컨테이너가 실행 중인 상태가 된 뒤에도 애플리케이션의 작업을 받아들일 준비가 되지 않을 수 있습니다. 부팅 로그에서 데이터베이스 상태가 정상으로 전환된 시점과 Immich의 첫 연결 오류를 비교하세요.

단순한 시작 순서만으로는 필요한 서비스가 실제로 준비되기 전에 종속 컨테이너가 시작될 수 있습니다. Compose 버전과 서비스 정의에서 지원한다면 상태 검사 기반 종속성 확인을 사용해 “컨테이너가 시작됨”과 “종속 서비스가 준비됨”을 구분할 수 있습니다. 느리거나 비정상적인 종속성을 숨기는 대신 불필요한 재연결 주기를 제거하는 데 활용하세요.

준비 상태 확인은 범위가 좁고 의미 있어야 합니다. 데이터베이스 확인은 Immich에 필요한 연결을 수락할 수 있음을 입증해야 하지만, 자체적으로 지연을 추가하는 값비싼 쿼리를 실행해서는 안 됩니다. 데이터베이스가 일관되게 Immich 시작보다 먼저 준비되면, 다른 것을 변경하기 전에 호스트 재부팅 테스트를 다시 수행하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

재시도 루프와 정상적인 시작 작업 구분하기

스토리지와 PostgreSQL이 준비되었는데도 재부팅 후 Immich가 훨씬 오래 걸린다면, 애플리케이션과 워커 로그에서 반복적인 연결 실패, 상태 검사 실패, 마이그레이션, 작업 초기화 또는 리소스 부족을 확인하세요. 일정한 간격으로 반복되는 오류는 대기 중임을 나타내는 경우가 많고, CPU나 디스크 작업이 계속되면서 진행 상황이 나타난다면 실제 시작 작업이 진행 중임을 의미합니다.

종속성 순서는 짧고 고정된 지연 시간보다 의미 있는 상태 검사와 함께 사용할 때 가장 효과적입니다. Compose 상태 검사 패턴을 사용하면 아직 초기화 중인 데이터베이스나 캐시와 애플리케이션이 경쟁하는 상황을 방지할 수 있습니다. 상태 검사를 현실적으로 유지하세요. 아픈 서비스가 정상인 것처럼 보일 때까지 간격을 줄여도 시작 성능은 개선되지 않습니다.

부팅 중 재시작 횟수가 증가한다면 CPU, 메모리 또는 이미지 시작 매개변수를 조정하기 전에 재시작 폭주를 멈추고 처음 사용할 수 없었던 종속 요소를 확인하세요. 컨테이너 재시작 루프 종속성 확인을 사용하면 느린 사전 조건과 Immich 내부 문제를 구분하는 데 도움이 됩니다.

다시 재부팅하고 실제 사용 가능 시간 확인하기

한 가지를 집중적으로 변경한 후 호스트를 완전히 재부팅하고 동일한 타임스탬프를 기록하세요. 실제 개선이라면 새로운 재시작 루프, 누락된 마운트 또는 백그라운드 오류를 만들지 않으면서 종속 요소가 준비된 시점부터 Immich 클라이언트를 사용할 수 있게 될 때까지의 간격이 줄어들어야 합니다.

웹 로그인 페이지만 테스트하지 마세요. 오래된 사진을 여러 장 열고, 검색을 실행하고, 대표적인 동영상을 로드하고, 모바일 클라이언트가 연결되는지 확인하며, 읽기 및 쓰기 경로를 모두 테스트할 수 있도록 삭제해도 되는 파일 하나를 업로드하세요. 가정에서 정상적으로 사용하는 작업이 작동하기 전까지는 서버가 “시작되었다”고 볼 수 없습니다.

첫 번째 성공적인 테스트 후 두 번째로 재부팅해 결과가 캐시 효과나 일회성 네트워크 타이밍에 따른 것이 아닌지 확인하세요. 시작 시간이 계속 일정하지 않다면 부팅 추적 기록을 보존하고 실행마다 준비 상태가 달라지는 구성 요소에 집중하세요. 더 나은 준비 상태 신호가 없지 않다면 긴 고정 지연 시간으로 변동성을 숨기지 마세요.