fio 测试中的 iodepth 到底是什么意思？是队列深度吗？

Question

我了解队列深度，即存储控制器可以处理的未完成 I/O 请求的数量（https://www.tomshardware.com/reviews/ssd-gaming-performance,2991-3.html）即，这是对处理 I/O 请求并将命令发送到磁盘 (r/w) 的存储控制器的限制，如果有超过它可以处理的请求（将由客户端重新提交），它（不严格？）会丢弃请求想必）。

并且具有高过期 I/O 请求的原因可能是多个客户端连接请求 I/O 或多个进程甚至来自请求 I/O 的单个主机（我认为，但似乎操作系统使用 I/O 调度程序合并 I/O O 请求 - 在执行定期或按需同步时源自缓冲区，并且仅发送固定数量的过期请求，以便它不会使存储设备过载？）

现在，来到 fio 手册页中 iodepth 的定义：

要针对文件保持运行的 I/O 单元数。请注意，将 iodepth 增加到 1 以上不会影响同步 ioengines（使用 verify_async 时的小度数除外）。

这符合我对队列深度的理解。如果 IO 是同步的（阻塞 IO），我们只能有一个队列。

即使是异步引擎也可能施加操作系统限制，导致无法实现所需的深度。在 Linux 上使用 libaio 并且未设置“direct=1”时可能会发生这种情况，因为缓冲 I/O 在该操作系统上不是异步的。

对这整个声明感到困惑。

密切关注 fio 输出中的 I/O 深度分布，以验证实现的深度是否符合预期。默认值：1。

我为每种 iodepth 和设备类型运行了多个测试，有 22 个并行作业，因为 CPU 数量为 24，并且使用 rwtype：顺序读取和顺序写入。Iodepths 是 1,16,256,1024,32768（我知道 32 或 64 应该是最大限制，我只是想尝试一下）。

对于所有深度和所有磁盘（RAID 6 SSD、NVME 和 NFS），结果几乎相同：除了在 32768 深度的 NVME 磁盘上顺序读取。

IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.9%
submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%

对于深度为 32768 的 NVME，

complete  : 0=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=100.0%

我在 fio 中使用了 libaio 引擎（因为我不确定我需要为异步 I/O 测试提供什么 IO 引擎，而 libaio 似乎是正确的。这是一个完全不同的问题）

发生什么了？为什么提交和完成显示 1-4（除了 NVME 的一次运行 >64）

[global]
lockfile=none
kb_base=1024
fallocate=posix
blocksize=64k
openfiles=100
ioengine=libaio
buffered=1
invalidate=1
loops=5
randrepeat=1
size=512M
numjobs=22

[sr-iodepth-1]
description="Sequential Write,Parallel jobs-22,IO depth-1,libaio"
readwrite=write
size=5G
iodepth=1

[sr-iodepth-16]
description="Sequential Write,Parallel jobs-22,IO depth-16,libaio"
readwrite=write
size=5G
iodepth=16

[sr-iodepth-256]
description="Sequential Write,Parallel jobs-22,IO depth-256,libaio"
readwrite=write
size=5G
iodepth=256

[sr-iodepth-1024]
description="Sequential Write,Parallel jobs-22,IO depth-1024,libaio"
readwrite=write
size=5G
iodepth=1024

[sr-iodepth-32768]
description="Sequential Write,Parallel jobs-22,IO depth-32768,libaio"
readwrite=write
size=5G
iodepth=32768


[sw-iodepth-1]
description="Sequential Read,Parallel jobs-22,IO depth-1,libaio"
readwrite=read
size=512M
iodepth=1

[sw-iodepth-16]
description="Sequential Read,Parallel jobs-22,IO depth-16,libaio"
readwrite=read
size=512M
iodepth=16

[sw-iodepth-256]
description="Sequential Read,Parallel jobs-22,IO depth-256,libaio"
readwrite=read
size=512M
iodepth=256

[sw-iodepth-1024]
description="Sequential Read,Parallel jobs-22,IO depth-1024,libaio"
readwrite=read
size=512M
iodepth=1024

[sw-iodepth-32768]
description="Sequential Read,Parallel jobs-22,IO depth-32768,libaio"
readwrite=read
size=512M
iodepth=32768

Answer 1

（请不要在一篇文章中提出多个问题 - 这会让回答变得非常困难......）

队列深度是未完成的 I/O 请求的数量 [...] 处理 I/O 请求并将命令发送到磁盘 (r/w) 并且它（不严格？）丢弃请求

过多的请求通常不会被丢弃 - 设备中没有任何地方可以将它们排队，因此其他东西（例如操作系统）必须保留它们并在空间可用时提交它们。他们没有迷失，只是没有被接受。

以及具有高过期 [sic] I/O 请求的原因

有许多不同的原因 - 您列出了其中之一。例如，设备可能很慢（想想旧式 SD 卡），甚至无法跟上一个“客户端”。

只有固定数量的过期 [sic] 请求，这样它就不会使存储设备过载？）

这是目标，但没有什么说设备能够跟上的（有时有合并不会发生的原因/配置）。

即使是异步引擎也可能施加操作系统限制，导致无法实现所需的深度。在 Linux 上使用 libaio 并且未设置“direct=1”时可能会发生这种情况，因为缓冲 I/O 在该操作系统上不是异步的。

对这整个声明感到困惑。

Linux 的一个怪癖是非O_DIRECTI/O（默认）通过缓冲区缓存（这就是所谓的缓冲 I/O）。正因为如此，即使您认为您已经异步提交（通过使用 Linux AIO），您实际上只是以同步行为结束。有关不同措辞的解释，请参阅https://github.com/axboe/fio/issues/512#issuecomment-356604533。

为什么是 Submit and complete 显示 1-4

你的配置是这样的：

buffered=1

你没有注意你之前想知道的警告！buffered=1是一样的说direct=0。即使您确实有direct=1，默认情况下一次fio提交一个 I/O，因此如果您的设备速度如此之快，以至于它在下一个排队之前完成了 I/O，您可能看不到深度大于 1。如果您希望强制/保证批量提交，请参阅HOWTO/manual 中iodepth_batch_*提到fio的选项。

好的，回到标题中的问题：

fio 测试中的 iodepth 到底是什么意思？

它是优秀的I / O的最高金额fio将尝试和队列内（即但要注意fio可能永远无法达到它上面给出以下原因）。

[iodepth] 是队列深度吗？

也许更进一步，它还取决于您所说的“队列深度”是什么意思。如果您指的avgqu-sz是 Linux 等工具所报告的那样，iostat那么根据所使用的 ioengine、与该 I/O 引擎一起使用的选项、I/O 的类型和样式等内容，它们iodepth 可能相似或大不相同提交，它必须经过的层直到它到达报告的级别等。

我认为您已经在很多不同的地方询问了这些问题的变体——例如，fio 邮件列表对上述某些问题有答案——并且该邮件提到您也在https://unix.stackexchange.com/questions 上发布 /459045/iodepth-in-fio 究竟是什么。您可能需要小心，因为您可能会让人们回答实际上已经在其他地方回答过的问题，并且您没有将它们联系在一起，这使得发现重复的答案变得困难......