NVMe 큐 깊이는 벡터 인덱스 수집 속도에 어떤 영향을 미칠까요?

에바 왕

IceWhale author

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

How Does NVMe Queue Depth Affect Vector Index Ingest Speed? - Zima Store Online

NVMe 큐 깊이는 병렬 스토리지 작업을 노출해 벡터 수집 속도를 높일 수 있지만, 다른 단계나 장치가 포화되면 더 이상 향상되지 않습니다.

대규모 홈 아카이브를 임베딩하면 하나의 순차 파일이 아니라 벡터, 메타데이터, 그래프 엣지, 포스팅, 임시 실행 파일, 커밋 레코드가 생성됩니다. 인덱서가 쓰기 요청 하나만 제출하고 기다리면, 빠른 NVMe 장치는 명령 사이에서 유휴 상태가 됩니다. 처리 중인 요청을 늘리면 장치 내부의 병렬성을 활용할 수 있지만, 큐 깊이가 지나치게 높으면 대기열이 길어져 같은 드라이브를 공유하는 대화형 검색 성능이 저하될 수 있습니다.

큐 깊이는 파일 수가 아니라 처리 중인 명령 수를 측정합니다

NVMe는 제출 큐와 완료 큐를 쌍으로 사용합니다. 큐 깊이는 처리 완료를 기다리며 남아 있을 수 있는 명령의 수이므로, 파일 시스템과 블록 계층이 인덱스 작업을 장치 요청으로 변환한 뒤의 스토리지 동시성을 나타냅니다.

NVMe 사양은 호스트 소프트웨어가 각 명령의 완료를 기다리지 않고 여러 명령을 제출할 수 있도록 제출 큐와 완료 큐를 정의합니다. 이 설계는 여러 컨트롤러 채널, 플래시 다이, 내부 작업을 동시에 공급할 수 있습니다. 이러한 차이는 이후의 실제 가정 환경 테스트에서도 확인할 수 있습니다.

파일을 많이 연다고 해서 유용한 큐 깊이가 보장되는 것은 아닙니다. 동기식 애플리케이션 로직, 소규모 트랜잭션, 잠금 또는 각 레코드마다 수행하는 fsync는 요청이 컨트롤러에 도달하기 훨씬 전에 경로를 직렬화할 수 있습니다. 자동화를 진행하기 전에 중간 결과를 확인할 수 있어야 합니다.

병렬 인덱스 작업은 큐 깊이를 처리량으로 전환합니다

벡터 수집 파이프라인은 문서 레코드를 일괄 처리하고, 임베딩을 병렬로 인코딩하며, 그래프 또는 역색인 구조를 구축하고, 비동기 쓰기를 실행할 수 있습니다. 충분한 독립 작업이 있으면 스토리지는 각 지연 시간을 순차적으로 드러내는 대신 프로그램, 지우기, 메타데이터, 전송 작업을 겹쳐 처리할 수 있습니다.

SPDK의 NVMe 성능 지침은 병렬 NVMe 큐와 작업자 배치를 장치 및 워크로드에 맞추는 것을 강조합니다. 애플리케이션이 독립적인 I/O를 제공하고 CPU가 완료를 효율적으로 폴링하거나 처리할 수 있을 때만 더 높은 동시성이 도움이 됩니다.

인덱스 구조도 중요합니다. 추가 작업이 많은 세그먼트 생성은 더 큰 배치로 확장될 수 있지만, 빈번한 그래프 변경, WAL 커밋 또는 소규모 메타데이터 업데이트는 CPU 또는 동기화에 계속 묶일 수 있습니다. 스토리지 작업을 너무 느리게 생성하는 단계는 큐 깊이로 가속할 수 없습니다.

포화 상태에서는 큐 깊이가 증가할수록 대기 시간이 늘어납니다

처리량은 플래시 대역폭, 컨트롤러 처리, PCIe, CPU 또는 인덱서 자체의 직렬화가 용량에 도달할 때까지 증가합니다. 그 변곡점을 지나면 추가 명령은 더 오래 기다리지만 초당 완료되는 바이트 수는 늘지 않고, p99 지연 시간과 처리 중인 버퍼에 사용되는 메모리만 증가합니다.

USENIX의 최신 NVMe 스토리지 연구는 NVMe 호스트 오버헤드가 단순한 명시 대역폭이 아니라 장치 아키텍처와 호스트 소프트웨어 오버헤드에 좌우된다는 점을 보여줍니다. 짧은 동시 요청은 병목을 CPU와 I/O 제출 경로로 옮길 수 있습니다.

실패가 발생하는 경계는 수집 작업이 검색, 모델 로딩, 데이터베이스 또는 스왑과 장치를 공유하는 혼합 워크로드입니다. 대량 수집을 최대로 만드는 큐 깊이는 전체 처리량이 매우 좋아 보여도 대화형 읽기를 사용할 수 없게 만들 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

검색 지연 시간을 숨기지 않고 처리량의 변곡점을 찾으세요

임베딩 작업자 수, 배치 크기, 인덱스 매개변수, 파일 시스템, 커밋 정책을 동일하게 유지한 채 큐 깊이 1, 2, 4, 8, 16, 32, 64에서 같은 코퍼스를 실행하세요. 이 경계는 실제 운영 조건에서 별도로 측정해야 합니다.

소규모 파일 인덱싱과 소규모 파일 동작을 비교하세요. 초당 벡터 수, 기록된 바이트, 장치 사용률, 평균 및 p99 쓰기 지연 시간, CPU 시간, fsync 빈도, 메모리, 동시 검색 p99를 기록하세요. 여러 소스가 제한된 컨텍스트를 놓고 경쟁할 때 실제 영향이 나타납니다.

대화형 지연 시간 요구 사항을 충족하면서 지속 가능한 최대 수집 처리량에 가까운 가장 낮은 큐 깊이를 선택하세요. 큐 깊이 1부터 처리량이 평평하게 유지된다면 NVMe를 탓하기 전에 임베딩, 잠금, 컴팩션, 커밋 빈도를 프로파일링하세요. 이 의존성은 최종 인터페이스에 명확하게 남겨야 합니다.