라이브러리 변경 후 Immich 백그라운드 작업이 급증하는 이유 kontaktannonser

라이브러리를 변경한 후 Immich의 백그라운드 작업이 급증할 수 있습니다. 파일 시스템 또는 라이브러리 이벤트 하나가 스캔, 메타데이터, 파생 파일 생성, 인덱싱 작업으로 확산될 수 있기 때문입니다.

중요한 구분은 예상된 재처리 작업이 제한된 규모로 한 번 진행되는지, 아니면 그에 상응하는 변경 없이 작업이 자산을 반복해서 다시 처리하는지입니다. 폴더 이동, 외부 라이브러리 재스캔, 새로 발견된 파일, 버전별 동작은 모두 비슷한 CPU 및 대기열 그래프를 만들 수 있으므로, 라이브러리 이벤트를 해당 이벤트가 생성한 정확한 작업과 연결해야 합니다.

라이브러리 스캔은 검색 단계이지 전체 작업량이 아닙니다

스캔은 먼저 Immich가 디스크에서 확인할 수 있는 내용과 라이브러리에 대해 이미 알고 있는 내용을 대조합니다. 새 자산이나 변경된 자산이 발견되면 이후 출력물이 오래되었거나 누락된 상태가 될 수 있으며, 이로 인해 스캔 자체가 끝난 것처럼 보인 뒤에도 추가 작업이 발생합니다.

겹치는 라이브러리 스캔에 관한 실무자 보고서에서는 스캔 대기열이 완료된 뒤에도 썸네일, 얼굴 인식 및 기타 대기열이 높은 수준으로 남아 있던 상황을 설명합니다. 여기서 핵심 메커니즘은 작업 확산입니다. 짧은 검색 단계가 훨씬 긴 후속 처리 작업을 생성할 수 있습니다.

대기열은 종속성 순서에 따라 해석하세요. 라이브러리 대기열이 0으로 떨어졌는데 파생 작업 대기열이 계속 진행된다면, 서버는 완료된 스캔이 생성한 작업을 단순히 처리하고 있는 것일 수 있습니다. 이 전체 기간을 반복 스캔이라고 부르면 실제로 리소스를 사용하는 단계가 무엇인지 알기 어려워집니다.

경로 변경은 새 자산 작업처럼 보일 수 있습니다

외부 라이브러리는 특히 파일 시스템상의 식별 정보와 경로 변경에 민감합니다. 파일을 재구성하면 애플리케이션이 저장된 자산 상태와 새 위치를 대조해야 할 수 있습니다. 버전과 라이브러리 유형의 동작에 따라 실제로 새로 추가된 사진 수보다 훨씬 많은 작업이 발생할 수 있습니다.

이동된 외부 파일에 관한 2026년 논의에서는 재구성된 경로가 새 자산으로 처리되어 썸네일, ML 분석 및 동영상 처리가 다시 실행된 사례를 다룹니다. 이는 알려진 제한 사항에 대한 보고서이지, 모든 폴더 이동이 동일하게 동작한다는 보장은 아닙니다.

이 때문에 라이브러리를 재구성하는 작업은 같은 수의 새 사진을 추가하는 것보다 훨씬 많은 비용이 들 수 있습니다. 그러나 파일 경로와 콘텐츠가 변경되지 않았다면 전체 재생성이 반복되는 것은 다른 조건을 시사하므로, 정상적인 백그라운드 동작으로 받아들이기보다 조사해야 합니다.

작업이 완료되는 동안 후속 대기열이 증가할 수 있습니다

대기 중인 작업 수가 계속해서 단조롭게 감소할 필요는 없습니다. 한 작업이 완료되면 자산이 다른 작업의 대상이 되거나 이후 단계에 더 많은 작업이 추가될 수 있습니다. 따라서 대규모 대조 작업 중에는 서버가 실제 진행 상황을 보이는 동시에 후속 대기열이 증가할 수 있습니다.

썸네일 적체에 관한 논의에서는 다른 처리가 완료되면서 새 썸네일 작업이 나타날 수 있다고 설명합니다. 또한 과거의 버그와 잘못 구성된 가져오기 경로가 비정상적인 반복을 만들 수 있다는 점도 보여 줍니다. 따라서 대기열 증가를 해석할 때는 버전과 경로 정보를 함께 고려해야 합니다.

대기 중인 작업 수만 보지 말고 완료된 작업 수와 최근 출력물을 일부 직접 확인하세요. 썸네일이 생성되고 완료 수가 증가하며 시간이 지나 새로 들어오는 작업보다 처리 속도가 빨라진다면, 원래 라이브러리 스캔이 끝난 뒤 대기열의 정점이 나타나더라도 대기열은 줄어들고 있는 것입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

일치하는 변경 없이 작업이 발생하면 급증은 비정상입니다

예상 가능한 백그라운드 부하는 새 자산, 메타데이터 새로 고침, 변경된 경로, 모델 변경 또는 명시적인 재생성 작업과 같은 분명한 이벤트로 설명할 수 있어야 합니다. 구성이나 콘텐츠의 변경 없이 동일한 기존 자산이 반복해서 예약된다면 그 설명은 설득력을 잃습니다.

한 스캔이 다른 라이브러리에 영향을 준 사례에서 여러 외부 라이브러리의 작업이 다시 생성된 것으로 보였던 것은 범위가 중요한 이유를 보여 줍니다. 이러한 보고서는 일반적인 Immich의 동작으로 간주하지 말고, 버전에 한정된 근거로서 자신의 로그와 비교해 사용하세요.

관련 대기열이 비워진 뒤에도 호스트가 계속 바쁜 상태라면 이 메커니즘만으로는 설명할 수 없습니다. 이 경우 데이터베이스 유지 관리, 백업, 다른 컨테이너, 파일 시스템 활동 또는 멈춘 프로세스를 확인하세요. 라이브러리 변경을 관련 없는 지속적인 부하의 만능 설명으로 사용해서는 안 됩니다.

변경 전후의 작업 지도로 변경 사항을 연결하세요

통제된 라이브러리 변경을 수행하기 전에 자산 수, 주요 작업의 대기 중 및 활성 작업 수, CPU 사용량, 스토리지 지연 시간, 마지막으로 완료된 스캔 시간을 기록하세요. 소규모의 알려진 자산 그룹을 추가하거나 이동한 뒤 같은 방식으로 다시 관찰하고, 정확히 어떤 대기열이 얼마나 빠르게 증가하고 줄어드는지 기록하세요.

ZimaSpace의 Immich 데이터 경로 설명을 활용해 각 급증을 검색, 처리, 데이터베이스 또는 스토리지에 할당하세요. 모든 백그라운드 활동을 하나의 범주로 취급해서는 안 됩니다.

생성된 작업량이 통제된 변경 규모에 비례하고, 출력물이 생성되며, 실패가 제한적이고, 대기열이 기준선으로 돌아간다면 해당 급증은 정상으로 볼 수 있습니다. 변경되지 않은 자산이 반복해서 재생성되거나, 작업 범위가 수정한 라이브러리를 초과하거나, 동일한 작업이 진전 없이 계속 실패한다면 추가 조사가 필요합니다.