Immich가 CPU, 메모리, 네트워크 또는 스토리지 중 무엇에 의해 병목 현상이 발생하는지 테스트하는 방법

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

반복 가능한 한 가지 작업으로 Immich를 테스트하고, 리소스 대기 시간과 지연 시간을 연관 지어 관찰한 다음, 통제된 개입으로 의심되는 병목을 확인하세요.

대시보드 스냅샷만으로는 유용한 활동과 해로운 경합을 구분할 수 없습니다. 고정된 미디어와 클라이언트 조건에서 업로드 수락, 썸네일 표시 또는 스마트 검색 응답과 같은 하나의 엔드포인트를 측정한 다음, 병목으로 의심되는 리소스만 변경하세요.

하나의 엔드포인트와 재현 가능한 기준선 정의하기

먼저 관찰 가능한 방식으로 엔드포인트의 이름을 정하세요. “Immich가 느리다”는 테스트할 수 없지만, “재시작 후 동일한 타임라인 썸네일 20개가 표시되는 데 4초가 걸린다”는 테스트할 수 있습니다. 이후 실행에서 의도한 변수 하나만 달라지도록 클라이언트, 네트워크 경로, 계정, 사진 세트 및 시작 조건을 고정하세요.

Immich의 데이터 경로 모델은 업로드, 처리, 데이터베이스 선택 및 미디어 전송이 서로 다른 종속 요소를 거친다는 점을 보여 줍니다. 검색 선택을 대상으로 하는 테스트에서는 이미지 렌더링과 결과 목록 표시 시간을 따로 측정해야 합니다. 그렇지 않으면 빠른 쿼리 뒤에 느린 파일 읽기가 이어지는 상황이 하나의 구분되지 않은 지연으로 보고됩니다.

기준선 측정은 최소 세 번 실행하고 중앙값과 가장 느린 유효 백분위수도 기록하세요. 큐 깊이, 컨테이너별 CPU, 메모리 압박, 스왑 활동, 네트워크 처리량 및 재전송, 디스크 지연 시간, I/O 큐 깊이를 기록하세요. 병목 주장은 리소스 신호와 엔드포인트 지연 시간이 일치해야 합니다.

CPU 포화와 메모리 압박 구분하기

CPU 중심 실행에서는 실행 가능한 작업이 프로세서 시간을 기다리므로 엔드포인트 지연 시간이 지속적인 코어 포화 또는 스로틀링과 함께 증가해야 합니다. 메모리 중심 실행에서는 회수, 스왑, 컨테이너 종료 또는 모델의 반복 로딩이 대신 나타날 수 있습니다. 두 경우 모두 CPU 차트가 바쁘게 보일 수 있지만, 개입에 따른 반응은 서로 다릅니다.

최근의 독립적인 Immich 리소스 가이드는 전체 RAM을 하나의 요구 사항으로 취급하지 않고 서버, PostgreSQL, Redis 및 머신러닝 구성 요소별 사용량을 설명합니다. 이 서비스 수준의 관점이 중요한 이유는 호스트에 여유 메모리가 있어도 컨테이너 제한이 너무 낮을 수 있고, 대용량 파일 캐시가 있다고 해서 반드시 메모리 부족 상태인 것은 아니기 때문입니다.

메모리는 일정하게 유지하면서 백그라운드 작업자 동시성을 낮추거나 더 많은 CPU를 할당하여 CPU 압박을 확인하세요. 작업자 수는 변경하지 않고 스왑 활동을 제거하거나 제한된 메모리 한도를 높여 메모리 압박을 확인하세요. 엔드포인트가 일관되게 개선되지 않는다면 이 테스트에서 해당 리소스를 주요 경계로 판단하지 마세요.

네트워크 지연과 스토리지 지연 구분하기

원격 미디어는 두 요소를 모두 거치기 때문에 네트워크와 스토리지 제한이 함께 나타나는 경우가 많습니다. 링크가 포화되면 초당 전송 바이트 수가 제한되고, 스토리지 경합이 발생하면 링크가 한가하더라도 읽기 또는 쓰기 완료 시간이 늘어납니다. 따라서 원격 클라이언트에서만 테스트하면 느린 파일 전송의 원인을 잘못된 계층으로 판단할 수 있습니다.

Kingston의 SSD 분석은 대표적인 순차 속도 외에도 스토리지 응답에 영향을 주는 백그라운드 작업, 펌웨어 동작, 캐싱 및 호스트 명령을 강조합니다. Immich에서는 작은 썸네일 및 데이터베이스 작업이 많으므로 단일 대용량 파일의 대역폭 결과보다 지연 시간과 큐 동작이 더 유용한 지표입니다.

서버 데이터 세트는 변경하지 않고, 먼저 유선 로컬 클라이언트에서 엔드포인트를 반복한 다음 일반적인 원격 경로에서 반복하세요. 별도로 호스트에서 대표적인 파일 세트를 읽으면서 장치 지연 시간을 관찰하세요. 로컬 클라이언트에서만 개선된다면 네트워크 경로가 원인일 가능성이 높고, 호스트 측 대기가 지속된다면 스토리지 또는 해당 마운트가 원인일 가능성이 높습니다.

-15% OFF

개입 매트릭스를 사용해 각 원인을 수용하거나 배제하기

테스트 전에 CPU, 메모리, 네트워크 및 스토리지의 네 행을 작성하세요. 각 행에 예상 증상 하나, 대상 개입 하나, 배제 조건 하나를 지정하세요. 이렇게 하면 결과가 나온 뒤 진단이 바뀌는 것을 막고, 여러 업그레이드를 한꺼번에 구매할 이유가 아닌 유용한 음성 결과를 얻을 수 있습니다.

상당한 인터넷 대역폭이 있는데도 썸네일이 지연된 사례를 다룬 공개 Immich 현장 보고서는 사양만으로는 충분하지 않은 이유를 보여 줍니다. 관련 증거는 미디어 집합, 캐시 상태, 작업, 클라이언트 및 애플리케이션 버전을 고정한 상태에서 대상 변경이 측정된 엔드포인트를 개선하는지 여부입니다.

프로세서 부담을 줄였을 때 지연 시간이 개선되는 경우에만 CPU를 원인으로 받아들이고, 메모리 회수 부담을 줄였을 때 개선되는 경우에만 메모리를 원인으로 받아들이세요. 경로 부담을 줄였을 때 개선되는 경우에만 네트워크를, 장치 또는 마운트 대기 시간이 낮아졌을 때 개선되는 경우에만 스토리지를 원인으로 받아들이세요. 두 개입이 모두 도움이 된다면 두 순서로 각각 반복하세요. 첫 번째 병목이 제거된 뒤에야 두 번째 병목이 드러날 수 있기 때문입니다.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.