검색 반응성이 저하되기 전에 Immich가 처리할 수 있는 동시 작업 수는 얼마인가요?

Immich에는 보편적으로 안전한 작업 수가 없습니다. 동시 작업자가 대화형 요청에도 필요한 리소스를 포화시키면 검색 성능이 저하됩니다.

두 서버가 동일한 수의 썸네일 생성, 메타데이터 처리, 머신 러닝 작업을 실행하더라도 검색 지연 시간은 크게 다를 수 있습니다. 따라서 유용한 한도는 대기열이 계속 줄어드는 동안 정의된 대화형 응답 목표를 유지할 수 있는 가장 높은 혼합 워크로드입니다.

작업 수만으로는 워크로드를 설명할 수 없습니다

동시성 값은 작업자 수의 상한일 뿐, 부하를 직접 나타내는 지표는 아닙니다. 썸네일 생성, 동영상 트랜스코딩, 메타데이터 추출, 머신 러닝 추론은 각각 필요한 연산량과 스토리지 작업량이 다릅니다. 가벼운 메타데이터 작업 4개는 인터페이스를 원활하게 유지할 수 있지만, 동영상 작업 2개는 같은 호스트를 훨씬 더 강하게 점유할 수 있습니다.

한 커뮤니티 보고서는 대규모 가져오기 후 머신 러닝의 CPU 사용량이 높아 동시 작업 수를 줄였고, 그 결과 부하는 낮아졌지만 완료 시간은 늘어났다고 설명합니다. 이는 핵심적인 상충 관계를 뒷받침합니다. 동시성을 낮추면 백그라운드 작업이 사라지는 것이 아니라 대기열이 더 느리게 처리되도록 하여 전면 작업의 응답성을 보호합니다.

각 대기열을 하나의 워크로드 유형으로 취급하세요. 어떤 작업이 활성 상태인지, 어떤 미디어 유형을 처리하는지, 하드웨어 가속을 사용할 수 있는지를 기록하세요. 작은 JPEG 파일을 기준으로 산출한 안전한 총 작업 수를 RAW 사진이나 긴 동영상에 그대로 적용할 수는 없습니다. 각 슬롯이 나타내는 작업량이 달라졌기 때문입니다.

검색 성능은 최초의 공유 포화 지점에서 저하됩니다

대화형 검색은 여러 공유 계층을 거칩니다. 요청이 애플리케이션에 도달하고, 데이터베이스가 결과를 선택하며, 썸네일을 읽고, 클라이언트가 이를 표시합니다. 백그라운드 작업자는 둘 이상의 계층에서 경쟁을 일으킬 수 있습니다. 모든 컨테이너가 정상 상태여도 최초로 포화되는 계층이 실제 동시성 상한이 됩니다.

Immich 성능 토론에서는 명목상 대역폭이 충분한 호스트에서도 썸네일 로딩이 지연된 사례를 설명합니다. 이는 링크 속도만으로는 병목 지점을 파악할 수 없는 이유를 보여줍니다. 느린 요청 중 어떤 대기 시간이 증가하는지 측정하기 전까지는 CPU 스케줄링, 데이터베이스 읽기, 파일 시스템 지연, 클라이언트 전송이 모두 원인 후보로 남습니다.

사용률은 지연 시간과 함께 확인해야 합니다. CPU 사용률이 높아도 검색 지연 시간이 안정적이라면 생산적인 포화 상태일 수 있지만, CPU 사용률은 보통 수준인데 디스크 대기 시간이 증가한다면 스토리지 대기열이 원인일 수 있습니다. 메모리 압박은 운영 체제가 사용 가능한 RAM을 캐시로 활용한다는 사실 자체가 아니라, 회수 작업이나 스왑으로 지연이 발생할 때 중요합니다.

검색 쿼리가 느리지 않아도 검색 가능 상태는 늦어질 수 있습니다

새 자산의 인덱싱 작업이 완료되지 않았다면 빠른 쿼리도 검색 가능한 컬렉션의 일부만 반환할 수 있습니다. 반대로 모든 항목의 인덱싱이 이미 끝났더라도 데이터베이스나 스토리지 접근이 경합을 일으키면 쿼리가 느려질 수 있습니다. 두 상황을 모두 “검색 성능 저하”라고 부르면 서로 다른 결과 지점을 숨기게 되어 잘못된 동시성 조정으로 이어집니다.

ZimaSpace의 Immich 데이터 경로 설명은 업로드 수락, 미리 보기 준비, 의미 기반 검색을 서로 다른 결과 지점으로 구분합니다. 이 구분은 부하 테스트에서 필수적입니다. 파일이 도착한 시각은 해당 파일의 표현이 검색 대상이 되는 시각을 대신할 수 없습니다.

고정된 가져오기 집합에 대해 두 가지 시간을 추적하세요. 하나는 이미 인덱싱된 대조 사진을 대상으로 한 대화형 쿼리 지연 시간을 측정하고, 다른 하나는 새로 가져온 사진이 미리 정한 검색에 나타날 때까지 걸리는 시간을 측정합니다. 전자는 현재 사용자의 경험을 보호하고, 후자는 동시성을 낮출 때 발생하는 처리량 비용을 보여줍니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

추측이 아니라 단계별 테스트로 한도를 찾으세요

대표적인 미디어 묶음을 만들고, 결과가 알려진 고정 검색 3개를 선택하세요. 활성 상태인 각 대기열에서 작업자 1명으로 시작해 가져오기를 실행하고, 동일한 관찰 구간 동안 검색 지연 시간의 중앙값과 지연 꼬리 구간, 대기열 처리율, CPU, 메모리 압박, 네트워크 처리량, 스토리지 대기 시간을 기록하세요.

일반적인 병목 현상 지침은 가장 바빠 보이는 차트를 선택하기보다 워크로드 변화와 CPU, 메모리, 디스크, 네트워크 및 종속성 대기 시간을 연관 지어 분석할 것을 권장합니다. 실행마다 동시성 제어 항목 하나만 변경하세요. 동일한 검색 순서와 미디어 집합을 반복하면 변경된 변수를 식별할 수 있습니다.

지연 꼬리 구간의 검색 목표가 실패하거나, 서버가 스왑을 사용하거나, 스토리지 대기 시간이 계속 높게 유지되거나, 오류가 발생하거나, 백그라운드 대기열이 더 이상 유용한 처리량을 늘리지 못하는 첫 단계에서 중단하세요. 콜드 재시작 후와 시스템이 예열된 상태에서 각각 이전 단계를 다시 테스트하세요. 이처럼 더 낮으면서 반복 가능한 단계가 해당 워크로드에서 방어 가능한 상한입니다.