为什么 fio 观察到的 iops 与 iostat 观察到的不同？

Question

最近，我正在尝试使用 fio 测试我的磁盘。我的fio配置如下：

[global]
invalidate=0    # mandatory
direct=1
#sync=1
fdatasync=1
thread=1
norandommap=1
runtime=10000
time_based=1

[write4k-rand]
stonewall
group_reporting
bs=4k
size=1g
rw=randwrite
numjobs=1
iodepth=1

在此配置中，您可以看到我将 fio 配置为使用直接 io 进行随机写入。在测试运行时，我使用 iostat 来监控 I/O 性能。而且我发现：如果我将fdatasync设置为1，那么fio观察到的iops大约是64，而iostat观察到的iops大约是170。为什么会这样呢？如果我不配置“fdatasync”，两个 iops 大致相同，但要高得多，大约为 450。为什么？据我所知，direct io 不会经过页面缓存，在我看来，这意味着无论是否使用 fdatasync 都应该花费大约相同的时间。

我听说 iostat 在某些情况下可能会得出错误的统计数据。那是真的吗？究竟什么情况会导致 iostat 出错？有没有其他工具可以用来监控 I/O 性能？

Answer 1

查看您的作业文件，您似乎不是针对块设备执行 I/O，而是针对文件系统中的文件执行 I/O。因此，虽然您可能会要求文件系统“将此数据放在该文件中的该位置”，但文件系统可能会变成多个块设备请求，因为它还必须更新与该文件关联的元数据（例如日志、文件时间戳、写入时复制等） ） 也。因此，当请求被发送到磁盘（这是您使用 iostat 测量的）时，原始请求已被放大。

还要记住的是，Linux 可能有一个用于该磁盘的 ioscheduler。这可以在提交到磁盘之前重新排列、拆分和合并请求/在堆栈中进一步返回它们。请参阅https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt 中nomerges 的不同参数以了解如何避免某些合并/重新排列，但请注意您无法控制太大的请求的拆分（但文件系统不会发出过大的请求） .

（PS：我不知道 iostat 是“错误的”，所以您可能需要询问直接说它的人以了解他们的意思）