寻求的解释/信息:Windows使用"fsync"(FlushFileBuffers)写入I/O性能

Question

这个问题是我发布的早期问题的后续跟进:Windows fsync(FlushFileBuffers)与大文件的性能.在哪里我找到了可能的解决方案,但也有新问题.

在对不同的情节进行基准测试时,我发现了许多令人惊讶的结果.我希望有人可以帮助解释或指出我解释这些结果的信息方向.

这个基准测试的作用是按顺序将8个页面(32 K)的随机块(大4096字节)写入文件,然后刷新写入.它总共写了200000页,总计800 MB和25000次刷新.在开始写入之前,文件的大小设置为其最终长度.

它支持总共4个选项,其中运行所有组合:

• FlushFileBuffers在写入批处理或正常刷新(NS)之后执行"fsync"/ 操作(FS).
• 在开始写入(LB)或将文件保留为空(E)之前将单个字节写入文件的最后位置.
• 使用正常缓冲的写入(B)或无缓冲/写通式(WT)写入(使用FILE_FLAG_NO_BUFFERING和FILE_FLAG_WRITE_THROUGH).
• 直接写入文件流,即通过文件句柄(F)或使用存储器映射(MM)间接写入文件.

下表总结了我对我的系统(具有慢速主轴磁盘的64位Win 7笔记本电脑)的所有这些选项组合的发现.

我发现的是,"fsynced"缓冲写入的性能与文件的一个令人难以置信的低吞吐量的大小,使大型文件这样做不可行组合呈指数下降.如果文件的最后一个字节写入(选项LB),吞吐量甚至更低,所以我担心在随机而不是顺序写入情况下,性能将更加显着.

然而令人惊讶的是,对于无缓冲/写入I/O,吞吐量保持不变,与文件大小无关.最初(前100-200 MB)它的吞吐量低于缓冲写入,但之后平均吞吐量迅速赶上并且完成写入800 MB的速度更快.更令人惊讶的是,如果文件的最后一个字节写入,吞吐量会增加2倍.

通过内存映射文件写入文件时,可以看到相同的指数性能下降,同样在使用无缓冲/写入标志打开文件的情况下.在这里,如果文件有一个字节写入其最后位置,性能会更差.

UPDATE 基于霍华德的解释这里和这里,我重新测试,而无需启动之前写创建一个新的文件(即打开现有的,充分的书面文件,并覆盖它).我已更新原始问题中的代码,以反映此测试所做的更改.结果部分符合他对Linux的解释和发现.但有一些值得注意的例外.下表给出了结果,红色亮点显著的变化,蓝色的亮点,其中的变化并没有出现,这是令人惊讶的(即不符合预期,如果在霍华德的解释中提到的效应在作怪唯一的).

对于具有"fsync"刷新的缓冲写入文件(即不通过memmap),性能现在已经从指数衰减变为恒定趋势.但是,它现在比以前的测试场景需要更长的时间.吞吐量是一个恒定的1.5 MB/s,在它开始之前大约20 MB/s,指数衰减到1.5 MB/s左右.看起来可能的解释是文件元数据也会在每次刷新时被刷新,从而导致完整的磁盘革命以寻找元数据的位置.

对于"直写"到文件场景,写入最后一个字节的结果现在是相同的,与霍华德的解释所期望的一致.

然而,对存储器映射的写入,有一个值得注意的例外,并没有真正改变,这是令人惊讶的.它们在写入性能方面仍然表现出相同的指数衰减(从大约20 MB/s衰减到1.8 MB/s开始).这表明正在发挥不同的机制.一个值得注意的例外是如果基础文件是在没有FILE_FLAG_WRITE_THROUGH的情况下创建的,则执行"fsync"刷新.此方案现在显示恒定(差)性能,吞吐量约为1.6 MB/s.由于我有些疑惑,我多次重复这种情况,每次给出相同的结果.

为了找出多一点,我也使用较小的文件(50000页,共计200 MB),以确认,该FSYNC性能(缓冲I/O)实际上是不依赖于文件大小重新运行该测试.结果显示如下,值得特别注意的结果用红色突出显示.

这些结果与较大文件的结果很好地相关.值得注意的变化是,对于那些突出显示的内容,写入更有效,它们似乎达到了大约7 MB/s的限制.

总结为基于对我的系统的观察到目前为止的高度推测性结论:

• "FSYNC"在Windows上使用缓冲IO文件(即没有FILE_FLAG_WRITE_THROUGH标志)的性能呈指数和已经写入到文件的字节数减少.原因似乎是每次都需要刷新文件元数据,这会导致磁盘搜索到文件的开头.
• 写入内存映射文件时,Windows上的"fsync"性能也会以指数方式降低性能.我目前没有解释造成这种情况的确切机制.

鉴于这种观察到的性能,至少在我的用例中,这两个I/O选项并不代表可行的解决方案.

根据Greg的建议,我将在关闭Windows磁盘缓存的情况下重新运行测试,并且我还将运行Howard提供的基准代码,以排除由于我自己的错误而导致结果偏差的可能性.

更新2 我已完成测试,目前正在编译结果.为了不写"完整的历史",我将用结果,发现和一些结论的摘要替换这个问题的当前内容.霍华德在这个问题上的答案,以及在.NET代码旁边运行他的c基准代码的能力是最有用的.应用程序的结果相关性很好.Rlb的回答帮助我更好地理解了与磁盘相关的"合理数字".谢谢.

问题的一部分仍未得到答复.特别与在写入存储器映射时观察到的降低(和依赖于文件大小)性能有关.这可能与寻找/元数据刷新,但目前尚不清楚,我为什么/如何.

Answer 1

您会看到同步运行的速度呈指数下降，因为这些工作负载并不像您认为的那样纯粹是顺序工作负载。由于您每次都从一个新文件开始，因此您的写入会增加文件，并且文件系统中的元数据需要更新。这需要多次查找，并且随着文件的增长，从文件末尾到元数据的查找所需的时间越来越长。我还错误地将其发布在您的其他问题上，请参阅此处的完整答案： https: //stackoverflow.com/a/18429712/894520