Immich는 왜 밤새 반복적인 디스크 활동을 일으키나요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Does Immich Cause Repeated Disk Activity Overnight? - Zima Store Online

Immich는 예약된 유지 관리, 데이터베이스 작업, 대기 중인 미디어 작업 또는 재시도가 사람들이 라이브러리 사용을 중단한 후에도 계속되기 때문에 밤새 반복적인 디스크 활동을 일으킬 수 있습니다.

조용한 가정이라고 해서 서버가 유휴 상태라는 뜻은 아닙니다. 중요한 것은 같은 시각에 동일한 프로세스와 작업이 읽기 또는 쓰기를 설명하는지 확인하는 것입니다. 먼저 활동의 원인을 서로 연관 지은 다음, 예상된 작업인지, 밀린 작업을 처리하는 것인지, 아니면 중단해야 할 반복 루프인지 판단하세요.

무언가를 변경하기 전에 디스크 급증과 시간을 대조하세요

한 번의 시끄러운 관찰보다 3일 밤 동안의 타임스탬프를 기록하는 것부터 시작하세요. 블록 I/O가 증가하는 시점, 사용량이 높은 장치, 읽기와 쓰기 중 어느 쪽이 우세한지, 패턴이 거의 같은 시각에 시작되는지를 기록하세요. 시작 시간이 반복되면 스케줄러를 가리키고, 패턴이 불규칙하면 새로 유입된 작업, 재시도 또는 다른 컨테이너일 가능성이 더 큽니다.

Immich 배포 환경에서는 사용량이 적은 시간대에 데이터베이스 백업과 무결성 관련 작업을 예약할 수 있으므로, 이른 아침의 급증은 의도된 것일 수 있습니다. 디스크를 깨운다는 이유만으로 작업을 비활성화하지 마세요. 먼저 활동 시간대 이후에 해당 백업, 유지 관리 결과 또는 대기열 완료 기록이 나타나는지 확인하세요.

인접한 ZimaSpace의 Immich 유휴 시간대 백그라운드 작업 진단도 동일한 타임스탬프 원칙을 사용합니다. “유휴” 상태를 장애로 간주하기 전에 눈에 보이는 증상을 프로세스 및 작업과 연결하세요.

PostgreSQL 쓰기와 미디어 읽기를 분리하세요

새 사진을 열지 않는 동안에도 Immich 애플리케이션 상태가 변경되면 PostgreSQL이 계속 활성 상태일 수 있습니다. 데이터베이스 체크포인트, 미리 쓰기 로그, VACUUM 관련 작업 및 일반적인 애플리케이션 업데이트는 수천 개의 미디어 파일을 스캔하는 작업과 I/O 특성이 다릅니다. 사진 라이브러리를 탓하기 전에 트래픽을 수신하는 경로 또는 장치를 확인하세요.

pg_stat_io 분석의 PostgreSQL 관측성 논의에서는 읽기, 쓰기, 백엔드 활동, 체크포인터 동작 및 백그라운드 쓰기를 분리해야 하는 이유를 설명합니다. 이 구분을 활용해 데이터베이스 장치가 유용한 트랜잭션을 저장하느라 바쁜 것인지, 아니면 무언가가 반복적으로 과도한 작업을 일으키는 것인지 확인하세요.

미디어 디스크는 절전 상태를 유지하는데 데이터베이스 쓰기만 작고 주기적으로 발생한다면 정상적인 데이터베이스 정리 작업일 수 있습니다. 반대로 작업이 진행되지 않는 동안 동일한 데이터베이스 파일에 지속적으로 대량의 쓰기가 발생한다면, 전체 라이브러리를 더 빠른 저장소로 옮기기보다 로그를 보존하고 원인이 되는 쿼리 또는 재시작 루프를 조사하세요.

백그라운드 대기열이 실제로 진행 중인지 확인하세요

밤새 진행된 작업 전후로 작업 화면을 열어 대기 중, 활성, 실패 및 완료된 작업을 비교하세요. 썸네일 생성, 동영상 처리, 메타데이터 추출, 머신러닝 작업 또는 가져온 라이브러리 처리는 대규모 변경 후에도 저장 장치를 계속 사용하게 만들 수 있습니다. 대기열이 줄어들고 있다면 유용한 작업이 진행되고 있다는 증거입니다.

설명되지 않는 지속적인 읽기에 대한 최근 커뮤니티 보고서는 반대되는 진단 기준을 보여줍니다. 예상되는 작업이 없는데 매우 높은 읽기가 계속된다면 이를 “Immich의 정상 동작”으로 간주하지 말고 조사해야 합니다. 보고된 속도는 기준값이 아니라 하나의 사례로만 취급하세요.

동일한 몇몇 작업이 실패한 뒤 대기열에 다시 들어가면 진행 없이 디스크 활동이 반복될 수 있습니다. 첫 번째 오류와 영향을 받은 에셋 하나를 기록한 다음 해당 작업 유형을 분리하세요. 루프의 원인이 특정 파일, 권한, 저장소 지연 또는 서비스 종속성 때문인지 확인하기 전에 모든 대기열을 지우거나 전체 라이브러리를 다시 생성하지 마세요.

-15% OFF

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

Single board computer zimaboard2

드라이브 소음으로 추측하지 말고 프로세스에 I/O를 귀속하세요

다음 재발 시 호스트 수준의 I/O 모니터링을 사용해 장치를 읽거나 쓰는 프로세스를 확인하세요. 그런 다음 해당 프로세스를 Immich 서버, PostgreSQL, 머신러닝, 백업 도구, 바이러스 백신, 파일 시스템 스크럽 또는 관련 없는 컨테이너와 연결하세요. 드라이브 LED와 팬 소음만으로는 어떤 프로세스가 원인인지 알 수 없습니다.

실용적인 iotop 작업 흐름은 프로세스를 우선시하는 방법을 보여줍니다. 짧은 순간의 급증은 관찰 사이에 사라질 수 있으므로 여러 샘플을 기록하세요. 목표는 증상이 나타나는 동일한 시간대에 해당 프로세스를 포착하는 것입니다.

Immich가 최상위 I/O 사용자가 아니라면 Immich 설정 변경을 중단하고 실제 프로세스를 추적하세요. PostgreSQL, Immich 또는 관련 워커가 원인이라면 해당 프로세스의 로그 및 작업 진행 상황을 I/O 샘플과 대조하세요. 그러면 “서버가 매일 밤 시끄럽다”는 문제가 특정 구성 요소와 트리거로 좁혀집니다.

정상적인 야간 작업과 장애의 경계를 정하세요

활동이 알려진 일정이나 최근 라이브러리 변경 시점에 시작되고, 유용한 작업을 완료하며, 실패 수가 증가하지 않고, 저장소 지연 시간과 대기열 깊이가 기준 상태로 돌아온다면 정상으로 간주할 수 있습니다. 향후 증가 여부를 비교할 수 있도록 정상적인 소요 시간을 기록하세요.

빈번한 데이터베이스 쓰기에 관한 과거 Immich 논의는 눈에 보이는 사용자 작업 없이도 일부 데이터베이스 활동이 발생할 수 있음을 보여줍니다. 버전과 배포 환경은 달라질 수 있으므로, 이 사례는 데이터베이스를 별도로 측정해야 한다는 근거로만 활용하고 지속적인 모든 쓰기를 정상이라고 단정하지 마세요.

대기열이 중지된 후에도 I/O가 계속되거나, 동일한 오류가 반복되거나, 저장소 지연이 주간 사용에 영향을 주거나, 여유 공간이 예상치 않게 줄거나, 패턴이 매일 밤 심해진다면 문제를 단계적으로 조사하세요. 큰 변경을 하기 전에 타임스탬프, 프로세스 I/O, 작업 수, 관련 로그, 파일 시스템 여유 공간 및 재현 가능한 트리거 하나를 보존하세요.