fio基准延迟解释

Question

我用fio来对我的SSD进行基准测试。但是，当我指定fsync=1（在每个write()之后将脏缓冲区同步到磁盘）参数时，我对报告的延迟感到困惑。

$ fio --name=test_seq_write --filename=test_seq --size=2G --readwrite=write --fsync=1
test_seq_write: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.3
Starting 1 process
test_seq_write: Laying out IO file(s) (1 file(s) / 2048MB)
Jobs: 1 (f=1): [W] [100.0% done] [0KB/31968KB/0KB /s] [0/7992/0 iops] [eta 00m:00s]
test_seq_write: (groupid=0, jobs=1): err= 0: pid=10994: Thu Oct 26 09:09:19 2017
  write: io=2048.0MB, bw=35647KB/s, iops=8911, runt= 58831msec
    clat (usec): min=2, max=1099, avg= 9.42, stdev=18.19
     lat (usec): min=2, max=1099, avg= 9.56, stdev=18.28

在这里，iops是8911，因此延迟大约应该在100us左右。但是，报告的延迟是9us。我很好奇fio包括fsync的时间吗？我正在阅读fio doc，但没有找到任何解释。

Answer 1

（哦，天哪，如果你有任何选择，请不要使用蹩脚的旧版本的fio - 自从fio 2.1.3以来你已经修复了很多错误，你继续使用它本身就是一种伤害（而且它没有'需要花很多钱去build newer fio versions）。看看我们现在最新发布的fio版本：https://github.com/axboe/fio/releases）

以下答案适用于fio 3.4及更早版本。有关fio 3.5及更新版本，请参阅later answer to this question。

---

fsyncs是对常规I / O的单独fio操作（有关它们排队的位置，请参阅https://github.com/axboe/fio/blob/0bcf41cdc22dfee6b3f3b2ba9a533b4b103c70c2/io_u.c#L2170） 所以是的，他们应该算在内 。 [更新]但是，fio明确排除了不是从统计信息收集中读取，写入或修剪的I / O（请参阅https://github.com/axboe/fio/blob/0bcf41cdc22dfee6b3f3b2ba9a533b4b103c70c2/io_u.c#L1823）。

所以

fio是否包含fsync的时间[在I / O延迟统计中]？

没有fio在延迟统计信息中不包含fsync时间。 fsync将影响总带宽，但这将无法分配。

注意：fsync是一个繁重的操作，因为在Linux上它确保：

1. I / O已被确认为被“磁盘”接收，而不仅仅是在Linux的页面缓存中。
2. 与整个文件关联的元数据已刷新到磁盘。由于复杂的原因，这可能意味着您最终还要等待其他文件的数据/元数据被刷新...
3. “磁盘”已经承认I / O已经达到了稳定的存储空间（即它不仅仅是在“磁盘”缓存中无法承受失去的功率）。

通常在进行基准测试时，您更有兴趣确保只有1.因为至少那时您更接近于测试磁盘的速度（而不是Linux的缓存），而其他要点与确保数据完整性有关。如果这也是你的情况，我建议你使用direct=1和fio停止使用fsync，因为这样每个I / O都会绕过Linux的页面缓存，直到磁盘确认收到I / O后才会返回。因此，每个I / O都会在其时间内构建“磁盘延迟”，但如上所述，这并不意味着第2或第3点。另请注意，并非所有文件系统都支持此选项（这是一个遗憾）。

[原始猜测]

然而，它也可能是写I / O快速完成的情况，fsyncs快速完成但每次提交之间的空间非零（主要是由于fio必须工作）。所以做I / O - > I / O完成 - >做非I / O工作 - >做I / O等因此你不能从IOP中推断出I / O延迟（你只能给它一个上限）。

PS：您可以使用现代fio版本打开每个I / O日志记录（http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-write-lat-log，http://fio.readthedocs.io/en/latest/fio_doc.html#log-file-formats，http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-log-avg-msec（log_avg_msec必须为0 /未设置））但请注意，fsyncs也可以免于此日志记录。确保将日志保存在不会干扰测试的地方并注意每个I / O日志记录增长非常快，因此在此模式下不要进行太多I / O是个好主意。

PPS：这个问题最好发送到fio邮件列表（https://github.com/axboe/fio/blob/fio-3.1/README#L58）。

Answer 2

fio 3.5 or later is now able to report fsync latencies！在执行符合以下所有条件的工作负载时，您将看到此信息：

• 执行某种形式的写入
• 有一个fsync/fdatasync/sync_file_range设置
• --output-format是正常的（将有fsync / fdatasync / sync_file_range部分）或json / json +（这些值记录在“sync”方向下）。

以下是显示fsync延迟的正常输出示例：

$ ./fio --filename=/tmp/fio.tmp --size=1m --bs=512 --name=go --rw=write --fdatasync=1
go: (g=0): rw=write, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=psync, iodepth=1
[...]
go: (groupid=0, jobs=1): err= 0: pid=26958: Wed Feb 21 14:06:11 2018
  write: IOPS=512k, BW=250MiB/s (262MB/s)(1024KiB/4msec)
    clat (nsec): min=673, max=12144, avg=709.40, stdev=260.94
[...]
  lat (usec)   : 2=0.05%, 4=0.05%, 20=0.05%
  fsync/fdatasync/sync_file_range:
    sync (nsec): min=353, max=5307, avg=364.78, stdev=115.66
    sync percentiles (nsec):
     |  1.00th=[  358],  5.00th=[  358], 10.00th=[  358], 20.00th=[  362],
     | 30.00th=[  362], 40.00th=[  362], 50.00th=[  362], 60.00th=[  362],
     | 70.00th=[  362], 80.00th=[  362], 90.00th=[  366], 95.00th=[  366],
     | 99.00th=[  370], 99.50th=[  370], 99.90th=[  402], 99.95th=[ 2064],
     | 99.99th=[ 5280]
[...]

所以回答你的问题：

我很好奇fio包括fsync的时间吗？

在fio 3.3及以下no（参见https://stackoverflow.com/a/46968852/9109338的更新）。在fio 3.5及更高版本中，类型-fio不包括lat / clat延迟中的fsync（毕竟它不知道fsync延迟应该归因于哪些I / O因为它无法检索该信息）但是它帐户和报告自己的fsync延迟。