不同的Linux / APIs对NVMe SSD的性能基准测试有什么影响？(libaio对SPDK对io_uring)

Question

我正在我的Linux服务器上对NVMe SSD进行基准测试，目的是实现产品规范中提到的IOPS、BW和延迟值。

我最初使用FIO作为工作负载生成器，并使用libaio作为I/O引擎，但我越深入到存储域中，我就意识到它是一个过时的API，无法修复，因为它只为未缓冲的访问提供异步操作，以及庞大的系统开销。

这论文：“理解现代存储API:对libaio、SPDK和io_uring的系统研究”，帮助我全面理解了完成I/O命令的后端操作，并通过扫描设备数量、核心计数和(软件)队列深度对三者进行了比较。但是，一些参数没有被处理，因为它不在应用程序开发透视图的范围内，例如作业数量(作为不同的工作/进程)、线程、不同块大小和测试类型(seq/随机R/W)的影响，这些影响都严重影响到这些数据。

我的问题是:是否每个库都能满足SSD (即提供规格中提到的数字)？如果是，那么使用给定的库进行基准测试可以吗？在基准测试中，我的意思是在不同的配置(如单核/多核、单线程/多线程、R/W组合等)中实现最大吞吐量和最小延迟。如果不是，那么这是否意味着像libaio这样的过时技术永远无法与现代设备速度相媲美，也不应该再使用它(因为使用操作系统级瓶颈来定义设备速度是不公平的)？

我认为基准测试只应由API来完成，API也用于正在对设备进行基准测试的应用程序中。但这感觉有违直觉，因为对硬件设备进行基准测试不应该受到不相关的操作系统操作的影响，这甚至不是应用程序的属性。与普通同步I/O相比，我还想知道在操作的每一步中查找延迟开销的方法。

我觉得这里的事情都没有得到足够的记载，我希望能更深入地了解和思考这个领域里有经验的人。谢谢!

Answer 1

我的问题是:是否每个库都能满足SSD (即提供规格中提到的数字)？

io_uring有较少的开销，所以它可以更快。但是如果你的CPU足够快，libaio也可以饱和一个SSD。

我的测试：

-ioengine=libaio -numjobs=1：

   iops        : min=286708, max=386670, avg=381760.92, stdev=13237.78, samples=59

-ioengine=io_uring -numjobs=1：

   iops        : min=399008, max=414024, avg=409571.12, stdev=2658.33, samples=59

(+7%)

-ioengine=libaio -numjobs=2：

   iops        : min=779822, max=814588, avg=805774.92, stdev=2274.38, samples=118

-ioengine=io_uring -numjobs=2：

   iops        : min=438596, max=853962, avg=810650.24, stdev=38096.63, samples=118

(差不到1% )

-ioengine=libaio -numjobs=4：

   iops        : min=843282, max=1160188, avg=1131725.17, stdev=12340.14, samples=236

-ioengine=io_uring -numjobs=4：

   iops        : min=1031955, max=1163986, avg=1140789.00, stdev=5196.52, samples=236

(再次少于1%的差)

进一步增加numjobs并没有改变任何事情，看起来SSD已经饱和了。

fio完整命令行：

fio -ioengine=XXX -direct=1 -name=test -bs=4k -iodepth=32 -rw=randread -runtime=30 -filename=/dev/nvmeYYY -numjobs=ZZZ -group_reporting

SSD是三星pm9a3。