Ubuntu Linux中的异步IO io_submit延迟

Question

我正在寻找关于如何让高效和高性能的异步IO在我的应用程序上运行在Ubuntu Linux 14.04上的建议。

我的应用程序处理事务并在磁盘/闪存上创建一个文件。当应用程序处理事务时，会创建额外的块，这些块必须附加到磁盘/闪存上的文件中。应用程序还需要在处理新事务时频繁读取此文件的块。除了创建必须附加到该文件的新块之外，每个事务可能还需要从该文件读取不同的块。有一个传入的事务队列，应用程序可以继续处理队列中的事务，以创建足够深的IO操作管道，以隐藏磁盘或闪存上的读取访问或写入完成的延迟。对于尚未写入磁盘/闪存的块(由前一个事务放入写入队列)的读取，应用程序将停止，直到相应的写入完成。

我有一个重要的性能目标-应用程序应该产生尽可能低的延迟来发出IO操作。我的应用程序需要大约10微秒来处理每个事务，并准备好向磁盘/闪存上的文件发出写入或读取。发出异步读取或写入的额外延迟应尽可能小，以便应用程序可以在仅需要文件写入时，以尽可能接近每个事务10个usecs的速率完成每个事务的处理。

我们正在试验一个使用io_submit发出读写请求的实现。我将感谢任何关于我们需求的最佳方法的建议或反馈。io_submit会给我们带来最好的性能来达到我们的目标吗？对于每个写入io_submit的延迟和每个读取io_submit的延迟，我应该期待什么？

使用我们的实验代码(运行在2.3 GHz Haswell Macbook Pro，Ubuntu Linux 14.04上)，当扩展输出文件时，我们测量了大约50个写io_submit的使用。这太长了，我们甚至还没有接近我们的性能要求。任何能帮助我以最小延迟发起写请求的指导都将不胜感激。

Answer 1

我在这里以proposed Boost.AFIO的作者身份发言。

首先，Linux KAIO (io_submit)几乎总是阻塞的，除非O_DIRECT打开，并且不需要区段分配，如果O_DIRECT打开，您需要在4Kb对齐的边界上读取和写入4Kb倍数，否则您将强制设备执行读-修改-写操作。因此，除非您将应用程序重新构建为对O_DIRECT和4Kb对齐的i/o友好，否则使用Linux KAIO将一无所获。

其次，永远不要在写入过程中扩展输出文件，您会强制进行区段分配，可能还会刷新元数据。相反，将文件的最大范围错误定位为某个适当的较大值，并保留文件末尾的内部原子计数器。这应该会将问题减少到区段分配，对于ext4来说，区段分配是批处理和惰性的-更重要的是，您不会强制元数据刷新。这应该意味着ext4上的KAIO将在大部分时间内是异步的，但不可预测的是，当它将延迟的分配刷新到日志时，将会同步。

第三，我解决你的问题的方法可能是使用原子追加(O_APPEND)而不使用O_DIRECT或O_SYNC，所以你要做的就是将更新追加到内核页面缓存中不断增长的文件中，这是非常快速和并发安全的。然后，您会不时地垃圾收集日志文件中哪些数据是陈旧的，哪些区段可以使用fallocate(FALLOC_FL_PUNCH_HOLE)释放，这样物理存储空间就不会永远增长。这推动了将存储的写入合并到内核上的问题，在内核中已经花费了大量的精力来提高速度，而且因为这是一个始终向前推进的写入，所以您将看到写入以与写入顺序相当接近的顺序命中物理存储，这使得断电恢复变得简单。后一种选择是数据库如何做到这一点，实际上日志归档系统也是这样做的，尽管您可能需要对软件进行实质性的重新设计，但该算法已被证明是在通用问题情况下延迟与持久性之间的最佳平衡。

如果上面所有这些看起来像是大量的工作，操作系统已经提供了所有这三种技术结合到一个高度调优的实现中，这更为人所知的是内存映射: 4Kb对齐的i/o，O_DIRECT，从不扩展文件，所有的异步i/o。在64位系统上，只需将文件错误定位到非常大的数量并将其映射到内存中。读和写你认为合适的东西。如果你的i/o模式混淆了可能发生的内核分页算法，你可能需要在这里或那里使用page ()来鼓励更好的行为。相信我，在me ()中，少就是多。

很多人试图使用不同的O_DIRECT算法复制mmap，而没有意识到mmap已经可以做你需要的一切。我建议先探索一下这些，如果Linux表现不佳，试试FreeBSD，它有一个更可预测的文件i/o模型，然后再深入研究你自己的i/o解决方案。作为一个整天都在做这些事情的人，我强烈建议你尽可能避免它们，归档系统是怪异和怪异行为的魔鬼的坑。将永无止境的调试工作留给其他人。