실제 Immich 성능의 한계를 가장 자주 결정하는 종속 요소는 무엇인가?

Immich 성능은 일반적으로 하나의 영구적인 하드웨어 사양이 아니라, 특정 워크플로에서 현재 활성화된 종속 요소 중 가장 느린 요소에 의해 제한됩니다.

업로드, 스마트 검색, 타임라인 탐색, 동영상 재생은 클라이언트, 네트워크, 서버, 데이터베이스, 워커, 스토리지가 서로 다른 조합으로 연결된 경로를 거칩니다. 엔드포인트나 백그라운드 작업의 중첩이 달라지면 실제 한계도 변하므로, 유용한 용량 관련 답변은 구성 요소 목록이 아니라 경로에서 시작해야 합니다.

성능 한계는 엔드포인트에 귀속됩니다

성능 한계란 명시된 조건에서 한 작업이 달성할 수 있는 최대 유용한 처리율 또는 최소 지연 시간입니다. 이는 CPU 사용률이 가장 높은 지점이 아닙니다. 업로드 수락, 검색 선택, 화면에 표시되는 썸네일, 재생 가능한 동영상은 완료되는 시점이 서로 다르므로 종속성 체인도 서로 다릅니다.

ZimaSpace의 Immich 데이터 경로 문서는 업로드 수락, 처리 준비 완료, 검색 선택, 미디어 전달을 구분합니다. 이러한 구분은 머신러닝 워커를 개선하면 인덱싱은 빨라질 수 있지만 썸네일 전달은 바뀌지 않을 수 있는 이유와, 더 빠른 네트워크 접속으로 느린 데이터베이스 쿼리를 해결할 수 없는 이유를 설명합니다.

모든 문제 제기나 벤치마크에 대해 시작 이벤트, 종료 이벤트, 클라이언트, 미디어 집합, 캐시 상태, 백그라운드 작업량을 기록하세요. 그런 다음에야 필요한 단계를 그려야 합니다. 업스트림 작업이 더 빠르게 유입될 때 엔드포인트가 개선되지 않도록 만드는 서비스 시간 또는 대기열을 가진 단계가 한계를 결정합니다.

데이터베이스와 대기열 상태가 조정을 제한하는 경우가 많습니다

데이터베이스는 자산을 선택하고 애플리케이션 관계를 유지하며, 대기열 상태는 백그라운드 작업을 조정합니다. 컴퓨팅 워커에 여유 사이클이 있더라도 이들의 지연으로 검색, 가져오기 또는 준비 완료 처리가 제한될 수 있습니다. 반대로 대기열이 깊다는 것은 대기열 서비스 자체가 느리다는 뜻이 아니라, 유입되는 작업량이 워커 처리량을 초과한다는 의미일 수 있습니다.

아키텍처 심층 분석에서는 PostgreSQL이 사용자, 자산, 앨범, 벡터 임베딩을 저장하고 Redis가 비동기 작업 대기열을 관리한다고 설명합니다. 이 자료는 독립적인 배포 설명이며, 여기서 중요한 가치는 특정 리소스 수치가 아니라 종속성을 분리해 설명한다는 점입니다.

데이터베이스 응답 시간, 연결 대기 시간, 대기열 깊이, 분당 완료 작업 수를 함께 관찰하세요. 워커 처리량은 일정하고 데이터베이스 타이밍도 안정적인데 대기열 깊이만 증가한다면 워커가 유력한 한계입니다. 모든 단계가 데이터베이스 대기 구간에서 멈춘다면 워커 동시성을 늘리는 것이 오히려 한계를 악화시킬 수 있습니다.

스토리지, 메모리, 컴퓨팅은 병목을 서로 주고받습니다

메모리는 데이터베이스 페이지, 썸네일, 모델을 프로세서 가까이에 유지할 수 있습니다. 작업 집합이 더 이상 메모리에 들어가지 않으면, 이전에는 메모리 속도로 처리되던 요청에도 스토리지 지연이 들어옵니다. 반대로 새로 가져오는 동안에는 연산량이 많은 썸네일, 동영상, 머신러닝 작업이 지배적일 수 있습니다. 제한 요소는 상태와 작업량에 따라 바뀝니다.

Immich 자체 호스팅 분석은 애플리케이션과 데이터베이스에 필요한 비교적 적은 메모리와 더 큰 머신러닝 메모리 요구량을 구분하고, 모델 로딩의 영향을 설명합니다. 구체적인 수치는 릴리스와 모델에 따라 달라지지만, 종속성에 관한 교훈은 일정합니다. 전체 RAM 용량만으로는 어느 서비스가 작업 집합을 잃는지 알 수 없습니다.

콜드, 웜, 지속 단계의 결과를 비교하세요. 콜드 상태에서 웜 상태로 크게 향상된다면 모델 또는 캐시 로딩이 원인일 수 있고, 광범위한 쿼리에서 장치 지연 시간이 높다면 작업 집합 누락을 의심할 수 있으며, I/O가 안정적인데 컴퓨팅이 포화된다면 처리가 원인일 수 있습니다. 한 가지 제한을 변경한 뒤에는 전체 경로를 다시 실행하세요. 이제 다음 단계가 지배적인 병목이 될 수 있기 때문입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

엔드포인트에서 종속 요소로 이어지는 지도를 만드세요

업로드 수락, 검색 결과 응답, 마지막으로 표시되는 타임라인 썸네일, 동영상 시작을 각각 행으로 만드세요. 클라이언트 준비, 네트워크 전송, 애플리케이션 처리, 데이터베이스 또는 대기열 작업, 워커 처리, 스토리지 접근, 클라이언트 디코딩을 열로 추가하세요. 모든 엔드포인트에 모든 구성 요소를 배정하는 대신, 사용되지 않는 단계는 사용되지 않는 것으로 표시하세요.

2TB 가족 라이브러리의 썸네일 생성 오프로드에 관한 커뮤니티 보고서는 처리 용량과 NAS 스토리지 용량을 구분해야 하는 실제 필요성을 보여줍니다. 이 사례가 항상 오프로드가 필요하다는 것을 증명하는 것은 아니며, 대규모 가져오기에서 특정 워커 경로가 지배적일 수 있음을 보여주는 것입니다.

대표적인 실행 하나를 측정하고 실제로 관찰된 대기만 순위를 매기세요. 가장 유력한 단계에 대한 개입 하나와 그 개입을 기각할 조건 하나를 제안하세요. 엔드포인트가 개선되면 한계가 이동한 것이므로 지도를 갱신하고, 개선되지 않으면 해당 가설을 버리세요. 이렇게 하면 구매 목록이 아니라 근거에 기반한 추적이 만들어집니다.