Immich가 CPU, RAM, 스토리지 또는 네트워크 중 무엇에 의해 제한되는지 확인하는 방법

에바 왕

IceWhale author

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

How to Tell Whether Immich Is Limited by CPU, RAM, Storage, or Network - Zima Store Online

고정된 업로드, 탐색, 검색 또는 백그라운드 작업 부하를 한 번 재현하고, 같은 시간 구간의 완료율을 CPU 포화도, 메모리 압박, 스토리지 지연 시간, 네트워크 처리량과 연관 지어 Immich의 한계를 파악하세요.

높은 비율만으로는 병목이라고 할 수 없습니다. 머신 러닝 중 CPU가 가득 사용되는 것은 정상일 수 있고, 높은 RAM 사용량은 파일 시스템 캐시일 수 있으며, 업로드가 느린 원인은 휴대폰이나 Wi-Fi일 수 있습니다. 클라이언트에서 컨테이너와 호스트까지 측정하고, 대기열 진행 상황을 기록한 다음, 의심되는 제약 하나만 변경해 반복하세요. 같은 작업 부하가 개선되는 자원이 제어 한계입니다.

반복 가능한 테스트와 타임라인 하나 만들기

개선하려는 증상을 선택하세요. 고정된 미디어 배치 수집, 캐시되지 않은 원본 열기, 썸네일 생성, Smart Search 실행, 동영상 하나 트랜스코딩 등이 될 수 있습니다. 시작 시각, 첫 사용 가능한 결과, 완료, 실패, 작업 대기열의 변화를 기록하세요. 작업을 섞으면 결정을 내릴 수 없는 리소스 그래프만 만들어집니다.

한 사용자의 조사에서는 CPU, 메모리, 디스크, 네트워크 증거를 확인하려는 과정에서 Immich 배포 환경이 비정상적으로 느린 문제가 보고되었습니다. 해당 리소스 간 진단 관점은 유용하지만, 원인은 반드시 서버에서 고정된 테스트로 확인해야 합니다.

캐시가 준비된 후 한 번 더 반복하세요. 두 번째 실행이 훨씬 빠르다면 하드웨어가 일관되지 않다고 판단하지 말고 캐시 상태를 표시하세요. 두 실행 모두 같은 단계에서 멈춘다면 해당 타임스탬프를 호스트 및 컨테이너 지표와 담당 작업에 맞춰 확인하세요.

CPU 및 메모리 사용 패턴 식별하기

CPU 제한은 관련 코어에서 실행 대기 작업이 지속되고 작업이 그에 비례해 진행되는 형태로 나타납니다. 동시성을 낮추면 상호작용은 개선될 수 있지만 대기열을 비우는 시간은 길어질 수 있습니다. 전체 CPU 사용량이 낮아 보여도 스레드 하나가 가득 사용된다면 여유 용량이 있다고 가정하기 전에 프로세스별 및 코어별 화면을 확인하세요.

메모리 제한을 판단하려면 스왑 증가, 회수 작업, 메이저 페이지 폴트, OOM 종료 또는 컨테이너 재시작과 같은 압박 증거가 필요합니다. 캐시가 안정적이고 스왑이 없으며 지연 시간이 정상인 높은 메모리 사용량은 이 테스트를 통과하지 못합니다. 동시성이 낮은 워커 하나 또는 더 작은 모델로 다시 실행하고 완료 결과를 비교하세요.

보고된 Immich v2.5.5 썸네일 사례에서는 한 배포 환경이 극심한 메모리를 사용했습니다. 이 버전이 명시된 메모리 보고서는 실패한 작업과 릴리스를 확인할 근거가 되지만, 일반적인 RAM 요구량을 입증하지는 않습니다.

스토리지 지연 시간과 네트워크 처리량 구분하기

스토리지는 정확히 같은 작업이 실행되는 동안 장치 지연 시간, 대기열 깊이, 처리량, 파일 시스템 여유 공간 및 inode 가용성을 확인하세요. 많은 소규모 데이터베이스 및 썸네일 작업이 지연 시간이 높은 디스크를 기다린다면 초당 메가바이트가 낮지 않아도 스토리지가 병목일 수 있습니다.

네트워크는 클라이언트와 서버 양쪽에서 측정한 다음 로컬 경로와 원격 경로를 비교하세요. 전송과 동시에 포화된 링크, 재전송, Wi-Fi 재시도 또는 VPN 한계가 나타난다면 네트워크 제한을 의미합니다. 업로드 트래픽이 끝난 뒤에도 처리가 느리다면 대신 서버 측 대기열을 추적하세요.

ZimaSpace의 구형 하드웨어에서 실행할 수 있는 서비스 개요는 시스템 계획에 대한 맥락을 제공하지만, 이 진단은 장비의 연식이 아니라 관찰된 지연 시간과 작업 처리율을 근거로 해야 합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

제약 하나를 완화하고 같은 작업 부하로 검증하기

안전한 변수 하나만 변경하세요. 작업 하나의 동시성을 낮추거나, 임시 메모리 제한 테스트를 추가하거나, 활성 데이터 사본을 더 빠른 스토리지로 옮기거나, 유선 로컬 네트워크에서 테스트할 수 있습니다. 데이터 세트, 버전, 캐시 상태를 비슷하게 유지하세요. 완료 결과와 예측한 지표가 모두 개선되면 인과 관계 테스트를 통과한 것입니다.

유휴 상태의 평균값이나 단 한 번의 피크만 보고 하드웨어를 구매하지 마세요. 소프트웨어 오류, 여유 공간 문제, 경쟁하는 예약 작업을 제외한 뒤에도 중요한 작업 부하를 반복해서 제어하는 자원일 때 업그레이드할 가치가 있습니다.

실패를 다른 계층으로 옮기거나 대기열을 서비스 목표를 초과할 정도로 늘리는 변경 사항은 되돌리세요. 어떤 자원에서도 압박이 나타나지 않는데 시스템이 멈춘다면 작업 부하 정의, 타임스탬프, 컨테이너별 지표, 디스크 지연 시간, 네트워크 테스트, 대기열 진행 상황, 로그를 첨부해 에스컬레이션하세요. 이러한 패턴은 잠금, 종속성 또는 애플리케이션 오류일 수 있습니다.