다양한 Linux I/O API가 NVMe SSD 성능 벤치마크에 어떤 영향을 미치나요? (libaio 대 SPDK 대 io_uring)

제품 사양에 언급된 IOPS, BW 및 대기 시간 값을 달성하는 것을 목표로 Linux 서버에서 NVMe SSD를 벤치마킹하고 있습니다.

나는 FIO를 워크로드 생성기로 사용하고 처음에는 libaio를 I/O 엔진으로 사용하고 있었지만 스토리지 세계에 더 깊이 들어가면서 그것이 복구할 수 없을 정도로 망가진 오래된 API라는 것을 깨달았습니다. 버퍼링되지 않은 액세스에 대해서만 비동기 작업을 제공하는 데 따른 제한 사항과 엄청난 시스템 호출 오버헤드.

이것논문: "최신 스토리지 API 이해: libaio, SPDK 및 io_uring에 대한 체계적인 연구"는 I/O 명령을 완료하는 백엔드 작업을 완전히 이해하는 데 도움이 되었으며 장치 수와 코어 수를 스캔하여 세 가지를 비교했습니다( 소프트웨어) 대기열 깊이. 그러나 애플리케이션 개발 범위를 벗어나기 때문에 작업 수(다른 작업자/프로세스로 작동), 스레드, 다양한 블록 크기 및 테스트 유형(seq/random R/W)과 같은 일부 매개 변수가 해결되지 않습니다. , 이는 숫자에 심각한 영향을 미칩니다.

내 질문은: 모든 라이브러리가 SSD를 포화시킬 수 있습니까(예: 사양에 언급된 숫자 제공)? 그렇다면 벤치마킹을 위해 특정 라이브러리를 사용할 수 있습니까? 여기서 벤치마킹이란 다양한 구성(예: 단일 코어/멀티 코어, 단일/멀티 스레드, R/W 조합 등)에서 최대 처리량과 최소 대기 시간을 달성하기 위한 프로파일링 방법을 의미합니다. 그렇지 않다면 libaio와 같은 오래된 기술은 최신 장치 속도와 결코 일치할 수 없으며 더 이상 사용되어서는 안 된다는 의미입니까(OS 수준 병목 현상을 사용하여 장치 속도를 정의하는 것은 불공평하기 때문입니다)?

벤치마킹은 기기를 벤치마킹하는 애플리케이션에서도 사용되는 API를 통해서만 가능하다고 생각합니다. 그러나 하드웨어 장치 벤치마킹은 응용 프로그램의 속성도 아닌 관련 없는 운영 체제 작업의 영향을 받아서는 안 되기 때문에 이는 직관에 어긋나는 것 같습니다. 또한 일반 동기 I/O와 비교하여 작업의 각 단계에서 지연 시간 오버헤드를 찾는 방법도 알고 싶습니다.

나는 여기에 있는 내용이 문서화되어 있지 않다고 생각하며 현장에서 경험이 있는 사람으로부터 더 깊은 이해와 생각을 얻고 싶습니다. 감사해요!