Ubuntu Linux中的异步IO_提交延迟

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

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

我有一个重要的性能目标–应用程序应尽可能减少发出IO操作的延迟。我的应用程序大约需要10微秒来处理每个事务，并准备对磁盘/闪存上的文件进行写入或读取。发出异步读取或写入的额外延迟应尽可能小，以便应用程序可以在只需要文件写入的情况下，以尽可能接近每个事务10 usecs的速率完成每个事务的处理

我们正在试验一种使用io_submit发出写和读请求的实现。如能就满足我们要求的最佳方法提供任何建议或反馈，我将不胜感激。io_submit是否将为我们提供最佳性能以实现我们的目标？对于每次写入io_提交的延迟和每次读取io_提交的延迟，我应该期望什么

使用我们的实验代码（在2.3 GHz Haswell Macbook Pro、Ubuntu Linux 14.04上运行），我们在扩展输出文件时测量了写入io_提交的大约50个使用次数。这太长了，我们甚至没有接近我们的性能要求。任何帮助我以最小延迟启动写请求的指导都将不胜感激

我是以《这里》的作者身份发言的

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

第二，永远不要在写入期间扩展输出文件，您将强制执行数据块分配，可能还会强制执行元数据刷新。相反，将文件的最大范围衰减到某个适当的大值，并在文件末尾保留一个内部原子计数器。这将把问题减少到ext4的批处理和延迟的数据块分配上——更重要的是，您不会强制进行元数据刷新。这意味着ext4上的KAIO大部分时间都是异步的，但当它将延迟的分配刷新到日志时，它将不可预测地同步

第三，我可能会解决您的问题的方法是使用原子附加（O_append），而不使用O_DIRECT或O_SYNC，因此您要做的是将更新附加到内核页面缓存中不断增长的文件中，这是非常快速和并发安全的。然后，您会不时地对日志文件中过时的数据进行垃圾收集，并使用fallocate（FALLOC\u FL\u PUNCH\u HOLE）释放其数据块，这样物理存储就不会永远增长。这就将写入到存储的问题推到了内核上，在内核上花费了大量的精力来加快写入速度，而且由于这是一种始终向前的写入过程，因此您将看到写入以与写入顺序非常接近的顺序进入物理存储，这使得功耗恢复变得简单。后一种选择是数据库和日志归档系统如何做到这一点，尽管可能需要对软件进行大量重新设计，但该算法已被证明是通用问题案例中延迟与持久性的最佳平衡

如果以上这些看起来都是大量工作，那么操作系统已经提供了三种技术，它们结合在一起，形成了一个高度优化的实现，这就是众所周知的内存映射：4Kb对齐i/o、o_直接、从不扩展文件、所有异步i/o。在64位系统上，只需将文件延迟到非常大的数量，然后将其映射到内存中。读和写你认为合适的东西。如果您的i/o模式混淆了可能发生的内核页面算法，您可能需要在这里或那里使用madvise（）来鼓励更好的行为。相信我，madvise（）越少越好

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

LinuxAIO（有时称为KAIO或

libaio

）是一门黑色艺术，经验丰富的实践者知道其中的陷阱，但出于某种原因，它是一门黑色艺术。通过在web上的浏览和体验，我想出了几个例子，其中Linux通过

io_submit（）

异步I/O提交可能会（无声地）同步，从而将其转变为阻塞（即不再快速）调用：

您正在提交缓冲（也称为非直接）I/O。您将任由摆布