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 文档，但没有找到任何解释。

Answer 1

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+（值记录在“同步”方向下）。

以下是显示 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 及以下版本中否（请参阅 https://stackoverflow.com/a/46968852/9109338 中的更新）。在 fio 3.5 及更高版本中，有点 - fio 不包括 fsync 在 lat/clat 延迟（毕竟它不知道 fsync 延迟应该归因于哪些 I/O） t 检索该信息），但它会自行计算和报告 fsync 延迟。

Answer 2

（哦，天哪，如果您有任何选择，请不要使用老旧的 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。

---

fsync 是常规 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 [在 I/O 延迟统计中] 是否包括 fsync 的时间？

No 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 快速完成，fsync 快速完成但每次提交之间的空间非零（主要是由于 fio 必须工作）。所以做 I/O -> I/O 完成 -> 做非 I/O 工作 -> 做 I/O 等等。因此你不能从所达到的 IOP 中推断出 I/O 延迟（你只能给它一个上限)。

PS：您可以使用 modern fio 版本（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 / unset)) 但请注意 fsyncs 也不受此日志记录的影响。确保将日志保存在不会干扰测试的地方，并注意每个 I/O 日志的增长速度非常快，因此在此模式下不要执行太多 I/O 是个好主意。

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