我已经使用fio测试磁盘性能了一段时间。但就在最近，我发现了一件我无法理解的棘手问题。由于尺寸选项描述如下 (fio man page)：
大小= INT
此作业的I / O总大小。除非受其他选项（例如运行时）的限制，否则fio将一直运行，直到传输了这么多字节为止。除非给出了nrfiles和filesize选项，否则此数量将在作业的可用文件之间分配。如果未设置，fio将使用给定文件或设备的完整大小。如果文件不存在，则必须提供大小。也可以给出1到100之间的大小。如果给出大小= 20％，fio将使用给定文件或设备的完整大小的20％。
只要我能理解，尺寸不是太小就不能收集就可以了，但是我的测试，我把尺寸设置为128MB，2GB，800GB，结果不同：
size=128M, average iops = 165
size=2GB, average iops = 145
size=800GB, average iops = 78
在我看来，对于4KB块，128MB大小足以获得足够数量的IO来进行测试，性能不应受到大小的影响。但为什么尺寸更大，性能更差。
答案 0 :(得分：0)
您是否在测试期间禁用了文件系统缓存？ 我在测试期间总是使用的一些参数（http://linux.die.net/man/1/fio）：
direct=1
invalidate=1
randrepeat=0
do_verify=0
verify_fatal=0
答案 1 :(得分：0)
如果您正在测试旋转驱动器，测试更大的容量区域意味着磁头必须更远地覆盖所有数据。这需要更长的时间，更长的寻道时间会导致更低的IOPS。
答案 2 :(得分：0)
在向下到磁盘的路径中，可能存在多个“最大”块大小，并且不得高于它们。
例如，你可能认为你正在提交一个10MB的块，但幕后真正发生的是10MByte块被分解为64K字节大小的块，因为这是驱动程序可以接受的限制。这个10MByte的I / O不能被标记为已经完成，直到它的每个单独的部分被返回，所以你创建了不必存在的阻塞，并且你还为进行拆分的层创建了额外的工作。因此，如果您从512向上测试块大小，通常会看到吞吐量的初始优势，然后在实际开始变慢之前收益递减。
不是：，Linux有时会公开“最佳块大小”（参见https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-block中的“/ sys / block // queue / optimal_io_size”），这可能是也可能不是磁盘的真正最佳块大小。
答案 3 :(得分：0)
但是为什么尺寸更大，性能却很差
您没有包括正在运行的作业/命令行，因此以下只是一个猜测：
如果作业是不直接进入磁盘的（缓冲）写入作业，则简单的答案可能是“使用较大的size，在缓存已满之前可以缓存总写入量中的较少者不得不等待”。 Linux可以缓存缓冲的写操作（并返回已“完成”的写操作），但是它可以执行多少操作将取决于给定时间可用的RAM量。如果您写的内容远远多于RAM，那么您将开始看到后备设备的速度更高，因为当缓存已满时，只有在现有的写操作降级之后，才能缓冲新的写操作。