대규모 모바일 라이브러리 가져오기 중 Immich가 검색 색인 생성을 예약하는 방식

대규모 모바일 라이브러리 가져오기 작업 중에는 Immich가 검색 관련 백그라운드 작업이 모두 완료되는 속도보다 더 빠르게 자산을 수락할 수 있으므로, 검색 최신화가 업로드 완료보다 늦어질 수 있습니다.

필요한 작업이 대기 중이거나 실행 중이거나 공유 리소스를 두고 경쟁하는 경우에만 이러한 지연은 스케줄링 문제입니다. 자동으로 검색 실패를 의미하지는 않습니다. 유용한 모델은 파이프라인입니다. 새 자산이 작업을 만들고, 큐가 급증한 작업을 흡수하며, 워커가 해당 큐를 처리하고, 데이터베이스가 이후 검색에 필요한 결과를 받습니다.

대규모 가져오기는 서로 다른 작업을 한꺼번에 만듭니다

모바일 마이그레이션은 단순히 바이트를 복사하는 것 이상입니다. 수락된 각 자산은 썸네일, 메타데이터, 동영상 처리, 스마트 검색, 얼굴 인식 또는 기타 활성화된 기능을 위한 후속 작업을 만들 수 있습니다. 이러한 작업은 비용과 의존성이 서로 다르므로, 한 번의 가져오기로도 처리 속도가 서로 다른 여러 백로그가 생길 수 있습니다.

순차 작업 요청은 리소스가 제한된 호스트에서 사용자가 이러한 동작을 인지하는 이유를 보여 줍니다. 운영자는 무거운 작업이 겹치지 않고 한 번에 하나씩 실행되기를 원할 때가 있습니다. 하지만 이러한 요청은 리소스 경쟁의 증거일 뿐, 모든 서버에서 순차 실행이 최선이라는 증거는 아닙니다.

전체 대기 작업 수를 하나의 작업량으로 취급하지 말고, 각 큐를 유입량, 완료량, 실패량으로 측정하세요. 대규모 썸네일 백로그는 동영상 트랜스코딩 백로그와 다른 방식으로 종속 작업을 지연시킬 수 있으며, 꾸준히 줄어드는 큐와 동일한 항목을 반복해서 재시도하는 큐는 의미가 다릅니다.

큐 우선순위는 전역 리소스 제어와 다릅니다

시스템은 특정 작업의 우선순위를 높이거나 일시 중지하면서도 다른 유형의 작업을 계속 활성 상태로 둘 수 있습니다. 따라서 한 종류의 백그라운드 활동을 줄이는 가져오기 도구가 CPU 유휴 상태, 디스크 작업 중단, 즉각적인 검색 최신화를 반드시 보장하는 것은 아닙니다. 스케줄링 정책과 전체 리소스 소비는 서로 관련되어 있지만 동일하지는 않습니다.

immich-go 릴리스에는 업로드 중 충돌을 줄이기 위해 백그라운드 작업 일시 중지 기능이 도입되었습니다. 이 동작은 해당 가져오기 도구와 버전에 속하므로, 모든 Immich 모바일 가져오기가 동일한 작업을 자동으로 일시 중지한다고 일반화해서는 안 됩니다.

실질적인 판단 기준은 관찰 가능한 진행 상황입니다. 검색 관련 큐가 의도적으로 일시 중지된 상태에서 업로드가 계속 빠르게 진행된다면 새 자산을 검색할 수 있게 되는 시점은 자연스럽게 늦어집니다. 큐가 활성화되어 있는데도 완료량이 거의 0에 가깝다면 문제는 스케줄링 정책이 아니라 워커, 리소스 또는 특정 자산의 오류일 수 있습니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

큐가 증가한다고 해서 자동으로 장애인 것은 아닙니다

워커가 작업을 완료하는 속도보다 작업이 더 빠르게 유입될 때마다 백로그는 증가합니다. 의도적으로 과거 데이터를 가져오는 동안에는 일정 기간 일부 백로그가 증가하는 것이 정상입니다. 장애 신호는 큐의 최대 길이 자체가 아니라, 완료가 멈추거나 오류가 반복되거나 유입이 중단된 후에도 백로그가 줄어들지 않는 상황의 조합입니다.

이 20만 장 사진 마이그레이션과 같은 대규모 가져오기 논의는 운영자가 업로드 처리량과 후속 처리를 어떻게 구분하는지 보여 줍니다. 커뮤니티 경험은 무엇을 측정해야 하는지 파악하는 데 유용하지만, 다른 라이브러리에 적용할 보편적인 소요 시간 추정치로 바꿔서는 안 됩니다.

관련 작업이 완료되었는데도 동일한 인증 사용자가 알려진 자산을 여전히 가져오지 못한다면, 이 메커니즘으로는 검색 결과 누락을 더 이상 설명할 수 없습니다. 그 시점에는 가져오기 동시성을 계속 조정하기보다 검색 관련성, 필터, 권한, 모델 동작 또는 자산별 처리 상태를 확인하세요.

2개 경로 스케줄링 테스트를 실행하세요

기존에 색인된 콘텐츠를 위한 고정 경로 하나와 소규모 신규 가져오기를 위한 경로 하나를 만드세요. 가져오기 전에 이미 알려진 기존 검색의 응답 시간을 기록합니다. 가져오는 동안 동일한 검색의 응답 시간, 업로드 속도, 대기 및 완료 작업 수, 실패 수, CPU 압박, 메모리 압박, 스토리지 지연 시간을 일정한 간격으로 기록하세요.

Immich 데이터 경로에 대한 ZimaSpace 분석을 참고해 전송, 처리, 저장, 검색 단계를 구분하세요. 병목은 실제로 서비스 목표를 충족하지 못한 단계와 일치할 때만 해결 가능한 문제가 됩니다.

기존 검색이 가정에서 허용 가능한 수준을 유지하고, 신규 항목 큐가 계속 완료되며, 유입이 중단된 후 백로그가 줄어든다면 해당 스케줄을 사용해도 됩니다. 동일한 공유 리소스가 대화형 사용과 큐 진행을 모두 지연시킨다는 사실이 통제된 테스트에서 확인된 경우에만 백그라운드 동시성을 줄이거나 일정을 조정하세요.