.net - 是否值得同步 I/O 密集型线程以提高总体磁盘性能？

Question

我们的 Windows .NET 应用程序有几个 I/O 密集型线程，它们不断地写入磁盘(旋转媒体)。来自一个线程的写操作是在不知道另一个线程的写操作的情况下完成的，因此这意味着写请求以与执行调用相同的顺序命中 Windows I/O 管理器。

在我们的项目中已经讨论过这是否是正确的方法，或者我们是否可以通过同步写操作来获得一些性能，以便只有一个(或几个)线程执行写操作同时到磁盘(可能通过共享锁)。从理论上讲，这会减轻 CPU 的压力，并为我们提供更好的吞吐量(请注意，我们已经在所有操作中使用异步 I/O)。

我对整个想法有点怀疑，因为我认为我们将完成操作系统最初设计要解决的部分工作。现在已经进行了一些实验，它指出了根本没有好处的方向。我的印象是，只要缓冲区大小足够，何时将 block 写入磁盘的决定最好留给操作系统来决定。

那么有人可以启发我们吗？从多线程进程同步磁盘访问以获得性能是个好主意吗？例如，Windows 或 Linux 在这方面有什么区别吗？

Answer 1

The theory is that this would put less strain on the CPU

怎么可能呢？它的写入次数相同，但现在增加了同步。它会产生(一点)更多的 CPU 负载。

we would then be doing part of the job that the operating system originally was designed to solve.

遗憾的是，Windows 无法执行任何类型的智能 IO 调度。我不确定磁盘驱动程序的作用。对于 NCQ 和 SATA，肯定会有某种程度的操作重新排序。但我从未观察到 Windows 在 IO 方面做了一些智能的事情(除了预取效果很好)。

主要问题是要执行顺序 IO 还是随机 IO。

1. 顺序:多个顺序流导致 Windows 将流分解为 64KB 或 256KB 的 block ，使它们高度随机。这真是太糟糕了。在这种情况下，您可以通过智能地发出大型 IO 来获得数量级的性能。
2. 随机:一次发出许多 IO，以便磁盘硬件可以对它们重新排序。例如，SQL Server 有时会发出数千个问题(并在此期间完全阻止其他进程 - 请注意这一点。Windows 没有实际工作的 IO 公平性概念。)

我对 Linux 了解不多，但至少它有某种 IO 调度。 Windows 团队似乎不想解决这个问题。