큐 깊이와 블록 크기가 가정용 NAS의 랜덤 읽기 지연 시간에 어떻게 영향을 미치나요?

큐 깊이와 블록 크기는 한 번에 제출되는 작업량과 각 작업이 전송하는 데이터 양을 제어하기 때문에 랜덤 읽기 지연 시간을 변경합니다. 낮은 큐 깊이와 작은 블록 테스트는 한 요청이 얼마나 빨리 완료되는지 측정하고, 높은 큐 깊이 테스트는 스토리지 경로가 얼마나 많은 병렬 작업을 지속할 수 있는지 측정합니다.

따라서 동일한 NAS는 겸손한 4K QD1 IOPS, 훨씬 높은 4K QD32 IOPS, 그리고 강력한 대용량 블록 처리량을 모순 없이 보여줄 수 있습니다. 각 결과는 다른 작업 부하를 설명하며, 가장 빠른 벤치마크 수치는 대화형 데이터베이스, 사진 라이브러리 또는 컨테이너 앱을 가장 덜 대표할 수 있습니다.

큐 깊이와 블록 크기는 실제로 무엇을 제어할까요?

큐 깊이는 측정된 계층에서 미완료된 I/O 작업 수입니다. 큐 깊이는 미완료 I/O 요청을 제어하고, 블록 크기는 각 요청이 전송하는 페이로드 크기를 정의합니다.

QD1 테스트는 하나의 작업을 제출하고 완료될 때까지 기다린 후 다음 작업을 실행합니다. QD32 테스트는 여러 작업이 대기하거나 병렬로 실행되도록 허용하여 드라이브, 컨트롤러, 배열 및 네트워크가 작업을 겹칠 기회를 더 많이 갖게 합니다.

이 값들은 여러 계층에 존재합니다. 벤치마크 스레드 큐, 운영 체제 블록 큐, HBA, NVMe 제출 큐, NAS 프로토콜 크레딧, 개별 디스크 모두 서로 다른 미완료 수를 볼 수 있습니다.

왜 QD1이 스토리지 서비스 시간을 노출할까요?

하나의 미완료 요청이 있을 때 다음 작업은 병렬 작업 뒤에 숨을 수 없으므로 QD1은 단일 요청 서비스 시간을 노출합니다. 결과에는 장치 서비스 시간과 프로토콜, 파일 시스템, 컨트롤러, 네트워크 및 클라이언트 오버헤드가 포함됩니다.

따라서 QD1은 메타데이터 열기, 데이터베이스 페이지 로드, 썸네일 읽기 또는 다음 구조를 가리키는 포인터 추적과 같이 하나 또는 몇 개의 종속된 읽기 작업을 수행하는 사용자 대상 작업에 유용합니다.

이것은 완전한 용량 테스트가 아닙니다. 최신 SSD나 스트라이프 배열은 QD1이 제공하는 것보다 훨씬 더 많은 병렬 작업을 지원할 수 있으므로, 결과는 최대 총 IOPS를 과소평가할 수 있지만 단일 요청 응답성을 정확하게 나타냅니다.

왜 더 높은 큐 깊이가 IOPS와 지연 시간을 동시에 높일 수 있을까요?

더 많은 미완료 작업은 스토리지 채널을 바쁘게 유지하고 초당 완료 작업 수를 높일 수 있지만 높은 큐 깊이는 IOPS와 지연 시간을 함께 증가시킬 수 있습니다. 각 요청은 서비스 전에 더 오래 대기할 수 있습니다.

벤치마크는 시스템이 작업을 겹쳐 처리하기 때문에 더 많은 총 완료를 보고하지만, 모든 요청이 더 빨라진 것은 아닙니다. 장치나 어레이가 서비스 용량에 도달하면 추가 큐 깊이는 주로 대기열을 길게 만듭니다.

이것이 높은 큐 깊이 IOPS와 낮은 인터랙티브 지연 시간이 별개의 목표인 이유입니다. 백업 서버나 분석 작업은 깊은 병렬 처리의 혜택을 받을 수 있지만, 앱 요청은 하나의 중요한 읽기 완료 시간을 중요하게 생각합니다.

블록 크기가 IOPS, 처리량 및 대기 시간에 어떻게 영향을 미칠까요?

IOPS는 각 작업이 얼마나 많은 바이트를 이동하는지 설명하지 않고 작업 수만 계산합니다. 블록 크기는 IOPS와 처리량 간의 균형을 바꿉니다. 1000개의 4K 읽기는 1000개의 128K 읽기보다 훨씬 적은 데이터를 이동합니다.

작은 블록은 작업당 오버헤드를 강조하며 데이터베이스 페이지, 메타데이터 및 애플리케이션 상태에 일반적입니다. 더 큰 블록은 전송 효율성과 처리량을 향상시키지만 요청당 더 많은 바이트를 차지하여 장치, 네트워크 및 컨트롤러를 점유합니다.

더 큰 블록은 주어진 대역폭에 필요한 IOPS 수를 줄이면서 각 작업의 서비스 시간을 늘릴 수 있습니다. 혼합 애플리케이션은 NAS가 작은 메타데이터 읽기와 큰 미디어 또는 백업 전송을 모두 처리해야 하므로 두 가지 차원이 모두 필요합니다.

왜 캐시와 병렬 처리가 결과를 앱이 느끼는 것보다 더 좋게 보이게 할까요?

벤치마크 결과는 RAM, 컨트롤러 캐시, 클라이언트 캐시 또는 작은 작업 세트에 대한 반복 액세스에 의해 좌우될 수 있습니다. 캐시와 동시성은 콜드 읽기 지연 시간을 숨길 수 있습니다.

병렬 벤치마크 작업자는 하나의 애플리케이션 스레드보다 디스크, NAND 채널, CPU 코어, SMB 채널 또는 NVMe 큐에 요청을 더 효과적으로 분산할 수 있습니다. 이 테스트는 개별 콜드 앱 읽기가 동일한 이점을 받는 것이 아니라 전체 확장성을 증명합니다.

저장 매체를 테스트할 때 관련 캐시보다 큰 데이터 세트를 사용하고, 애플리케이션 캐싱이 실제 설계의 일부일 경우 별도의 웜 캐시 테스트를 실행하세요. 두 가지를 혼합하면 병목 지점이 불분명한 수치가 나옵니다.

홈 NAS 랜덤 읽기 테스트는 실제 작업 부하와 어떻게 일치해야 하나요?

유용한 벤치마크는 실제 애플리케이션이 변하는 차원을 다양하게 합니다. 현실적인 테스트는 최대 IOPS 값 하나를 보고하는 대신 작업 부하 큐 깊이와 일치해야 합니다.

QD1과 몇 가지 중간 깊이를 테스트하고, 4K 또는 8K 작은 읽기와 미디어 또는 백업 도구에서 사용하는 더 큰 블록을 포함하며, 평균과 p95, p99, 최대 지연 시간을 기록하세요. 저장소 변경을 비교할 때 클라이언트, 프로토콜, 암호화, 데이터 세트는 일정하게 유지하세요.

랜덤 읽기 테스트를 단독으로 그리고 실제 NAS를 공유하는 백그라운드 작업과 함께 실행하세요. 단독 벤치마크는 저장 경로를 명확히 측정할 수 있지만, 앱, 백업, 인덱싱 또는 패리티 경쟁 중 사용자가 경험하는 지연 시간은 드러내지 못합니다.

자주 묻는 질문

항상 큐 깊이가 높을수록 좋은가요?

아니요. 저장 경로가 포화될 때까지 총 처리량을 향상시킬 수 있지만 요청이 더 오래 대기할 수 있고 대화형 지연 시간이 악화될 수 있습니다.

왜 4K 랜덤 읽기 수치가 흔히 보고되나요?

작은 블록은 데이터베이스 페이지, 메타데이터, 애플리케이션 상태와 유사하며, 큰 순차 전송이 숨기는 작업당 오버헤드를 드러냅니다.

NAS 벤치마크는 QD32를 사용해야 하나요?

예상 작업 부하가 그만큼 많은 병렬 I/O를 생성할 수 있을 때만 그렇습니다. 대화형 홈 서버 앱에는 QD1과 중간 깊이를 포함하세요.

네트워크 지연이 랜덤 읽기 테스트를 지배할 수 있나요?

네. SMB 또는 NFS 왕복, 클라이언트 처리, 암호화, 스위치 큐가 장치 서비스 시간을 초과할 수 있으며, 특히 큐 깊이가 낮을 때 그렇습니다.

최종 요약

큐 깊이는 얼마나 많은 I/O가 대기하거나 병렬로 실행될 수 있는지를 결정하며, 블록 크기는 각 작업이 이동하는 데이터 양을 결정합니다. 큐 깊이가 높으면 총 IOPS가 증가할 수 있지만 요청당 지연 시간이 늘어나고, 블록 크기가 크면 처리량이 향상되면서 작업 수가 줄어듭니다. 유용한 홈 NAS 벤치마크는 가장 큰 수치를 선택하는 대신 실제 동시성, 데이터 크기, 캐시 상태 및 꼬리 지연 요구 사항과 일치해야 합니다.