c - 实时写入磁盘

Question

我有一个线程需要将数据从内存缓冲区写入磁盘数千次。我对每次写入需要多长时间有一些要求，因为需要清除缓冲区以使单独的线程再次写入该缓冲区。

我已经用dd测试了磁盘。我没有在其上使用任何文件系统，而是直接写入磁盘(使用direct标志打开它)。我能够以32K的块大小获得约100 MB/s的速度。

在我的应用程序中，我注意到我几乎无法以这种速度将数据写入磁盘。因此，我调查了正在发生的事情，发现有些写入需要很长时间。我的代码块看起来像(顺便说一下，这是在C中):

last = get_timestamp();
write();
now = get_timestamp();
if (longest_write < now - last)
  longest_write = now - last;

最后，我打印出最长的文字。我发现对于32K缓冲区，我看到的最长写入速度约为47ms。这太长了，无法满足我的应用程序的要求。我认为这不能完全归因于磁盘的旋转延迟。有什么想法正在发生什么，我能做什么来获得更稳定的写入速度？谢谢

编辑:
实际上，我正在使用我在上面声明的类型的多个缓冲区，并将它们之间的 strip 化到多个磁盘。解决我的问题的一种方法是仅增加缓冲区的数量以摊销长写入的成本。但是，我想使用于缓冲的内存量尽可能地小，以避免弄脏正在生成写入缓冲区的数据的线程的高速缓存。我的问题应该局限于处理将小块写入磁盘的延迟差异以及如何减少这种差异。

Answer 1

我假设您正在使用连接到标准计算机中内置磁盘 Controller 的ATA或SATA驱动器。这是一个正确的假设，还是您使用了任何非常规的东西(硬件RAID Controller ，SCSI驱动器，外部驱动器等)？

作为在工作中进行大量磁盘I/O性能测试的工程师，我想说这听起来很像您的写入内容被缓存在某个地方。您的“高延迟” I/O是最终清除了该缓存的结果。即使没有文件系统，也可以将I/O操作缓存在I/O Controller 或磁盘本身中。

为了更好地了解正在发生的情况，不仅要记录最大延迟，还要记录平均延迟。考虑记录最大10-15个延迟样本，这样您可以更好地了解这些高延迟样本的频率。另外，丢弃测试前两到三秒记录的数据，然后开始记录数据。在磁盘测试开始时可能会看到高延迟的I/O操作，这些操作并不能指示磁盘的真实性能(可能是由于磁盘必须恢复到全速，磁头必须这样做较大的初始搜寻，磁盘写入缓存被刷新等)。

如果要对磁盘I/O性能进行基准测试，建议您使用IOMeter之类的工具，而不要使用dd或自己滚动。 IOMeter使您可以轻松查看更改I/O大小，对齐方式等有什么不同，此外，它还跟踪许多有用的统计信息。

要求在一定时间内进行I/O操作是一件危险的事情。首先，系统上的其他应用程序可以与您竞争磁盘访问或CPU时间，几乎不可能预测它们对您的I/O速度的确切影响。您的磁盘可能遇到坏块，在这种情况下，它必须做一些额外的工作才能在处理I/O之前重新映射受影响的扇区。这引入了不可预测的延迟。您也无法控制OS，驱动程序和磁盘 Controller 的功能。由于许多不可预见的原因，您的I/O请求可能会在这些层之一中进行备份。

如果您对I/O时间有硬限制的唯一原因是因为您的缓冲区正在被重用，请考虑改用算法。尝试使用循环缓冲区，以便您可以在写入数据时从其中清除数据。如果发现填充的速度快于刷新的速度，则可以降低缓冲区使用率。另外，您也可以创建多个缓冲区并在它们之间循环。当一个缓冲区已满时，将该缓冲区写入磁盘并切换到下一个。即使第一个缓冲区仍在写入中，也可以写入新缓冲区。

对评论的回复:
您无法真正“摆脱内核”，它是系统中的最低级别，您必须经历一个或另一个程度。您可能能够为磁盘 Controller 构建驱动程序的自定义版本(前提是它是开源的)，并为应用程序使用“高优先级” I/O路径。您仍然受制于磁盘 Controller 的固件以及驱动器本身的固件/硬件，您不一定可以预测或做任何事情。

传统上，硬盘驱动器在执行大型顺序I/O操作时性能最佳。驱动程序，设备固件和OS I/O子系统将这一点考虑在内，并尝试将较小的I/O请求分组在一起，以便它们仅需生成对驱动器的单个大型I/O请求。如果一次仅刷新32K，则您的写操作可能会被缓存在某个级别，合并并一次全部发送到驱动器。通过克服这种结合，您应该减少I/O延迟“尖峰”的数量，并看到更统一的磁盘访问时间。但是，这些访问时间将比您通常看到的中等时间更接近“峰值”中的大时间。延迟峰值对应于一个I/O请求，该请求未与其他任何请求合并，因此不得不吸收磁盘查找的全部开销。请求合并是有原因的；通过 bundle 请求，您可以分摊多个命令上的驱动器查找操作的开销。击败合并将导致您执行比通常更多的查找操作，从而使总体I/O速度降低。这是一个折衷方案:您可以减少平均I/O延迟，但要以偶尔执行异常的高延迟操作为代价。但是，这是一个有益的折衷，因为与禁用合并相关联的平均等待时间的增加几乎总是比具有更一致的访问时间更有利的缺点。

我还假设您已经尝试调整线程优先级，并且这不是您的高带宽生产者线程因CPU时间而耗尽缓冲区刷新线程的情况。你确认了吗？

您说您不想打扰也在系统上运行的高带宽线程。您是否实际测试了各种输出缓冲区的大小/数量并测量了它们对另一个线程的影响？如果是这样，请分享您测量的一些结果，以便我们在集思广益时可以使用更多信息。

考虑到大多数计算机具有的内存量，从32K缓冲区移动到可循环通过4个32K缓冲区的系统对内存使用来说是无关紧要的。在具有1GB内存的系统上，缓冲区大小的增加仅代表系统内存的0.0092％。尝试移至交替/旋转缓冲区的系统(为简单起见，从2开始)，并测量对高带宽线程的影响。我敢肯定，额外的32K内存不会对其他线程产生任何明显的影响。这不应该“破坏生产者线程的缓存”。如果您一直在使用这些内存区域，则应始终将它们标记为“正在使用”，并且永远不要从物理内存中交换出来。要刷新的缓冲区必须保留在物理内存中才能使DMA工作，并且第二个缓冲区将在内存中，因为您的生产者线程当前正在对其进行写入。的确，使用额外的缓冲区会减少生产者线程可用的物理内存总量(尽管只是很小的一部分)，但是如果您正在运行需要高带宽和低延迟的应用程序，则应将系统设计为它有很多超过32K的可用内存。

与其尝试通过强制硬件和低级软件执行特定性能测试来解决问题，更简单的解决方案是调整软件以适合硬件。如果将最大写入延迟测量为1秒(为了获得更好的整数)，请编写程序，以使刷新到磁盘的缓冲区至少需要重用2.5-3秒。这样，您可以覆盖最坏的情况，并提供安全余量，以防万一确实发生了意外情况。如果您使用的系统会旋转3-4个输出缓冲区，则不必担心在刷新缓冲区之前重新使用缓冲区。您将无法过于紧密地控制硬件，并且如果您已经在写入原始卷(没有文件系统)，那么您与硬件之间就没有太多可以操纵或消除的东西。如果您的程序设计不灵活，并且看到 Not Acceptable 延迟峰值，则可以始终尝试更快的驱动器。固态驱动器不必“寻求”进行I/O操作，因此您应该看到相当均匀的硬件I/O延迟。