다중 앱 홈 서버에서의 Immich: 공유 리소스가 결과를 어떻게 바꾸는가

멀티 앱 서버에서 Immich 결과가 달라지는 이유는 컨테이너가 서로 별도의 프로세스 경계를 공유하더라도 CPU, 메모리, 스토리지, 네트워크 용량은 한정되어 있기 때문입니다.

사진 검색은 정오에는 빠르다가 다른 애플리케이션이 백업, 스캔 또는 트랜스코딩을 수행하는 동안 느려질 수 있습니다. Immich 설정이 바뀐 것은 아니지만 사용 가능한 리소스 예산과 캐시 내용이 달라졌으므로, 유용한 설명을 위해서는 호스트 전체의 워크로드를 살펴봐야 합니다.

컨테이너는 프로세스를 분리할 뿐, 물리적 용량을 분리하지 않습니다

컨테이너는 네임스페이스와 제어 가능한 제한을 제공하지만, 결국 동일한 프로세서에서 실행되며 대개 동일한 메모리 컨트롤러, 디스크, 네트워크 인터페이스에 접근합니다. Immich 서비스가 자체 제한 내에서 실행되더라도 공유 물리 장치나 커널 스케줄러에서 관련 없는 작업에 밀려 대기할 수 있습니다.

멀티 컨테이너 Immich 사용 사례 보고서에서는 평소 CPU 사용량이 적고 수십 개의 컨테이너를 실행하는 저전력 호스트를 설명합니다. 그렇다고 다른 환경에서도 동일한 결과가 보장되는 것은 아닙니다. 이 사례는 서비스 개수만으로는 근거가 부족하며, 실제로 겹치는 작업을 호스트 수준에서 관찰해야 하는 이유를 보여줍니다.

백업, 미디어 스캔, 다운로드, 데이터베이스, 동영상 트랜스코딩 등 예약 작업과 순간적으로 부하가 발생하는 모든 인접 작업을 기록하세요. 해당 작업의 시작 시각과 Immich 지연 시간을 함께 기록합니다. 상관관계가 인과관계를 증명하는 것은 아니지만, 반복적으로 시간이 일치한다면 의심되는 간섭을 검증하기 위한 일시 중지 또는 재스케줄링 실험을 설계할 수 있습니다.

메모리 경쟁은 캐시 상주 상태를 바꿉니다

자주 사용하는 데이터베이스 페이지, 썸네일, 모델 데이터가 메모리에 상주하면 Immich 성능이 향상됩니다. 인접 서비스가 작업 집합을 확장하면 메모리 부족으로 종료되는 상황이 아니더라도 해당 페이지가 축출될 수 있습니다. 그러면 다음 요청은 데이터가 메모리에 올라와 있던 동안에는 발생하지 않았던 스토리지 접근 또는 모델 로드 비용을 부담하게 됩니다.

Kingston의 서버 메모리 관련 설명에서는 충분한 용량이 메모리를 많이 사용하는 애플리케이션에서 느린 스토리지에 의존하는 일을 줄인다고 설명합니다. 이를 이 상황에 적용하면, 모든 홈 서버에 엔터프라이즈급 메모리가 필요하다는 뜻이 아니라 캐시 손실로 인해 겉보기에는 동일한 Immich 요청이 전혀 다른 물리적 작업으로 바뀔 수 있다는 뜻입니다.

인접 작업이 시작되기 전후의 페이지 캐시 활동, 스왑, 메이저 폴트, 스토리지 읽기를 비교하세요. Immich를 변경하지 않고 해당 작업을 일시 중지했을 때 캐시가 따뜻한 상태의 요청 동작이 복원된다면 메모리 상주 상태가 원인일 가능성이 있습니다. 전체 RAM 사용률이 높다는 사실만으로는 충분하지 않습니다. 정상적인 파일 시스템 캐시는 원래 유휴 메모리를 적극적으로 사용하기 때문입니다.

스토리지 큐는 관련 없는 서비스를 서로 연결합니다

백업은 대용량 파일을 스트리밍하는 동시에 Immich는 작은 데이터베이스 및 썸네일 작업을 수행할 수 있습니다. 전체 대역폭이 드라이브에 표시된 최대치보다 낮더라도 큐잉으로 인해 지연에 민감한 요청의 완료 시간이 늘어날 수 있습니다. 네트워크로 연결된 스토리지를 사용하면 동일한 경쟁 경로에 또 다른 스케줄러와 네트워크 경로가 추가됩니다.

ZimaSpace의 Immich 데이터 경로 관련 글에서는 검색 결과 선택과 표시되는 미디어가 서로 다른 단계이며 각기 다른 의존성을 가진다는 점을 보여줍니다. 이 구분은 스토리지 결합의 원인을 파악하는 데 도움이 됩니다. 결과 식별자는 빠르게 표시되지만 썸네일이 늦게 나타난다면, 데이터베이스 선택 자체가 느린 경우보다 경로의 뒤쪽 단계에 문제가 있을 가능성이 높습니다.

동일한 요청을 재현하면서 마운트별 장치 지연 시간과 큐 깊이를 측정하세요. 의심되는 I/O 중심 작업만 일시 중지한 뒤 캐시가 안정될 때까지 기다리고 같은 테스트를 반복합니다. 여러 번 번갈아 실행해도 개선 효과가 유지된다면 스케줄링 또는 스토리지 분리를 고려할 근거가 됩니다. 그렇지 않다면 CPU, 메모리 또는 네트워크 가설로 돌아가세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

일시 중지 후 재실행하는 격리 테스트를 사용하세요

동일한 타임라인 구간을 로드하거나 알려진 스마트 검색을 실행하는 것처럼 고정된 엔드포인트를 선택하고, 콜드 상태 또는 웜 상태 조건을 정의하세요. 전체 서비스를 실행한 상태에서 세 번 테스트합니다. 그런 다음 Immich를 재시작하지 않고 후보 인접 작업 하나를 일시 중지한 뒤, 동일한 클라이언트 시퀀스와 관찰 시간 동안 다시 테스트합니다.

업데이트 후 처리 작업 중 Immich가 심하게 경쟁했다는 한 보고서에서는 호스트가 바쁜 동안 다른 사진 서비스의 업로드가 실패한 사례를 설명합니다. 이는 특정 구성에서 발생한 사례이지 보편적인 한계는 아니지만, 정상적인 백그라운드 큐도 공유 용량을 충분히 소비해 다른 대화형 서비스의 성능을 저하시킬 수 있음을 보여줍니다.

일시 중지로 반복 가능한 지연 시간 변화가 발생하고 관련 리소스 대기 시간도 함께 줄어들 때만 간섭이 확인되었다고 판단하세요. 다음으로 동시성 낮추기, 예약 시간대 설정, CPU 할당량, 메모리 예약 또는 별도 스토리지 사용과 같은 좁은 범위의 완화책을 테스트합니다. 한 인접 작업을 격리하면 두 번째 한계가 드러날 수 있으므로 롤백 설정을 보존하세요.