如何从磁盘获得良好的并发读取性能

Question

我想问一个问题，然后用我自己的答案跟进，但也看看其他人有什么答案。

我们有两个大文件，我们想要同时从两个独立的线程中读取。一个线程将顺序读取fileA，而另一个线程将顺序读取fileB。线程之间没有锁定或通信，两者都尽可能快地顺序读取，并且两者都立即丢弃它们读取的数据。

我们在Windows上使用此设置的经验非常糟糕。两个线程的组合吞吐量大约为2-3 MiB / sec。驱动器似乎花费大部分时间在两个文件之间寻找后退和前进，大概在每次搜索后读取很少。

如果我们禁用其中一个线程并暂时查看单个线程的性能，那么我们可以获得更好的带宽（此机器约为45 MiB /秒）。很明显，糟糕的双线程性能是操作系统磁盘调度程序的假象。

我们可以采取哪些措施来提高并发线程读取性能？也许可以通过使用不同的API或以某种方式调整操作系统磁盘调度程序参数。

一些细节：

在具有2GiB RAM的计算机上，文件大小为2 GiB。出于这个问题的目的，我们认为它们不会被缓存并完美地进行碎片整理。我们使用了碎片整理工具并重新启动以确保是这种情况。

我们没有使用特殊的API来读取这些文件。这种行为可以在各种沼泽标准API中重复，例如Win32的CreateFile，C的fopen，C ++的std :: ifstream，Java的FileInputStream等。

每个线程在一个循环中旋转，调用read函数。我们改变了每次迭代从API请求的字节数，从1KiB到128MiB之间的值。改变这一点没有任何影响，因此在每次磁盘搜索之后，OS实际读取的数量不是由这个数字决定的。这正是应该期待的。

单线程和双线程性能之间的巨大差异在Windows 2000，Windows XP（32位和64位），Windows Server 2003以及使用和不使用硬件RAID5时都是可重复的。

Answer 1

问题似乎出现在Windows I / O调度策略中。根据我发现的here，有很多方法可以获得O.S.安排磁盘请求。虽然Linux和其他人可以在不同的策略之间进行选择，但在Vista Windows被锁定在单个策略之前：FIFO队列，其中所有请求以64 KB块分割。我相信这个策略是您遇到问题的原因：调度程序将混合来自两个线程的请求，导致磁盘不同区域之间的连续搜索。
现在，好消息是，根据here和here，Vista引入了一个更智能的磁盘调度程序，您可以在其中设置请求的优先级，并为您的流程分配最小的带宽。
坏消息是我发现在以前版本的Windows中无法更改磁盘策略或缓冲区大小。此外，即使提高进程的磁盘I / O优先级将提高其他进程的性能，您仍然会遇到线程相互竞争的问题。
我可以建议通过引入自制的磁盘访问策略来修改您的软件 例如，您可以在线程B中使用这样的策略（类似于线程A）：

if THREAD A is reading from disk then wait for THREAD A to stop reading or wait for X ms
Read for X ms (or Y MB)
Stop reading and check status of thread A again  

您可以使用信号量进行状态检查，也可以使用perfmon计数器来获取实际磁盘队列的状态。 X和/或Y的值也可以通过检查实际的转移率并自动调整它们来自动调整，从而在应用程序在不同的机器和/或O.S上运行时最大化吞吐量。您可以发现缓存，内存或RAID级别以某种方式影响它们，但通过自动调整，您将始终在每种方案中获得最佳性能。

Answer 2

我想在回复中添加一些进一步的说明。我们测试的所有其他非Microsoft操作系统都没有遇到此问题。 Linux，FreeBSD和Mac OS X（不同硬件上的最后一个）在从一个线程移动到两个线程时，在聚合带宽方面都优雅地降级。例如，Linux从~45 MiB / sec降低到~42 MiB / sec。这些其他操作系统必须在每次搜索之间读取更大的文件块，因此不会花费大量所有时间等待磁盘进行搜索。

我们的Windows解决方案是将FILE_FLAG_NO_BUFFERING标记传递给CreateFile，并在每次调用ReadFile时使用大（~16MiB）读取。由于以下几个原因，这是次优的：

• 当像这样读取时，文件不会被缓存，因此缓存通常没有任何优点。
• 使用此标志时的约束比正常读​​取（读取缓冲区与页面边界的对齐等）复杂得多。

（作为最后的评论。这是否解释了为什么在Windows下进行交换是如此地狱般的？即，Windows无法以任何效率同时对多个文件执行IO，因此在交换所有其他IO操作时，不得不特别慢。 ）

---

编辑以添加Will Dean的更多详细信息：

当然，在这些不同的硬件配置中，原始数据确实发生了变化（有时是实质性的）。然而问题是性能的持续降低，只有Windows在从一个线程移动到两个线程时会受到影响。以下是测试机器的摘要：

• 使用单驱动器运行Windows 2000，Windows XP（32位）和Windows XP（64位）的多个戴尔工作站（英特尔至强）。
• 运行Windows Server 2003（64位）且RAID 1 + 0的Dell 1U服务器（Intel Xeon）。
• 配备Windows XP（64位），Windows Server 2003和硬件RAID 5的HP工作站（AMD Opteron）。
• 我的家用无品牌PC（AMD Athlon64）运行Windows XP（32位），FreeBSD（64位）和Linux（64位），单驱动器。
• 我的家用MacBook（Intel Core1）运行Mac OS X，单个SATA驱动器。
• 我的家Koolu运行Linux的PC。与其他系统相比，它的功能非常不足，但我证明，在进行多线程磁盘读取时，即使是这台机器也可以胜过带有RAID5的Windows服务器。

所有这些系统的CPU使用率在测试过程中非常低，并且禁用了防病毒软件。

我之前忘了提及但我们也尝试了设置CreateFile标志的普通Win32 FILE_FLAG_SEQUENTIAL_SCAN API。这个标志没有解决问题。

Answer 3

看起来有点奇怪的是，你看到各种各样的Windows版本没有区别，单个驱动器和硬件raid-5之间没有任何区别。

这只是'直觉'，但这确实让我怀疑这是一个简单的寻求问题。除了OS X和Raid5之外，所有这些都是在同一台机器上试过的 - 你试过另一台机器吗？在此测试期间，您的CPU使用率基本为零吗？

您可以编写哪个最短的应用程序来演示此问题？ - 我有兴趣在这里试试。

Answer 4

我会在内存中创建某种线程安全锁。每个线程都可以等待锁定，直到它被释放。当锁变为空闲时，取出锁并读取文件一段规定的时间或一定数量的数据，然后释放其他任何等待线程的锁。

Answer 5

您在Windows下使用IOCompletionPorts吗？通过C ++的Windows有一个关于这个主题的深入章节，幸运的是，it is also available on MSDN。

Answer 6

保罗 - 看到了更新。非常有趣。

在Vista或Win2008上尝试它会很有趣，因为人们似乎在某些情况下报告了一些相当大的I / O改进。

我对不同API的唯一建议是尝试对文件进行内存映射 - 你试过吗？不幸的是，每个文件2GB，你将无法在32位机器上映射多个整个文件，这意味着这并不像它可能那么简单。