当前位置:首页> 正文

关于linux:POSIX异步I / O(AIO)的状态是什么?

关于linux:POSIX异步I / O(AIO)的状态是什么?

What is the status of POSIX asynchronous I/O (AIO)?

网上散布着许多页面,这些页面以不同的细节描述了POSIX AIO设备。它们都不是最新的。目前尚不清楚他们在描述什么。例如,这里的Linux内核异步I / O支持的"官方"(?)网站说套接字不起作用,但是我的Ubuntu 8.04.1工作站上的" aio.h"手册页似乎都暗示着它适用于任意文件描述符。然后还有另一个项目似乎可以在库层工作,甚至需要更少的文档。

我想知道:

  • POSIX AIO的目的是什么?鉴于我能找到的最明显的实现示例说它不支持套接字,所以整个事情对我来说很奇怪。它仅用于异步磁盘I / O吗?如果是这样,为什么要使用超通用API?如果不是,为什么磁盘I / O成为首先受到攻击的东西?
  • 我在哪里可以看到完整的POSIX AIO程序示例?
  • 有人真正使用过它吗?
  • 哪些平台支持POSIX AIO?他们支持哪一部分?有人真的支持所承诺的隐含"任何FD的任何I / O"吗?

我可以使用的其他多路复用机制非常好,但是随处可见的随机信息碎片使我感到好奇。


通过kqueue,epoll,IO完成端口等解决了有效执行套接字I / O的问题。进行异步文件I / O有点晚了(除了Windows的重叠I / O和solaris对posix AIO的早期支持)。

如果您要进行套接字I / O,最好使用上述机制之一。

因此,AIO的主??要目的是解决异步磁盘I / O问题。这很可能是Mac OS X仅支持常规文件而不是套接字支持AIO的原因(因为kqueue还是要好得多)。

写操作通常由内核缓存,并在以后清除。例如,当驱动器的读取头正好经过要写入块的位置时。

但是,对于读取操作,如果您希望内核对读取进行优先级排序和排序,则AIO实际上是唯一的选择。这就是为什么内核可以(理论上)比任何用户级别的应用程序做得更好的原因:

  • 内核不仅可以查看应用程序磁盘作业,还可以查看所有磁盘I / O,并且可以在全局级别对其进行排序
  • 内核(可能)知道磁盘读取头在哪里,并且可以以最佳顺序选择传递给它的读取作业,以将磁盘移动最短距离
  • 内核可以利用本机命令队列来进一步优化您的读取操作
  • 与使用readv()相比,使用lio_listio()可能比使用readv()发出更多的读取操作,尤其是如果您的读取不是(逻辑上)连续的,则可以节省少量的系统调用开销。
  • 使用AIO,您的程序可能会稍微简单些,因为您不需要额外的线程来阻塞读写调用。

也就是说,posix AIO有一个非常尴尬的接口,例如:

  • 事件回调的唯一有效且得到良好支持的方法是通过信号,这使得它很难在库中使用,因为这意味着使用来自进程全局信号名称空间的信号编号。如果您的操作系统不支持实时信号,则还意味着您必须遍历所有未完成的请求,以找出实际完成的请求(例如Mac OS X,而不是Linux)。在多线程环境中捕获信号也会带来一些棘手的限制。通常,您不能对信号处理程序中的事件做出反应,但是必须引发信号,写入管道或使用signalfd()(在Linux上)。
  • lio_suspend()具有与select()相同的问题,但是随着作业数量的增加,它的扩展性不是很好。
  • lio_listio(),由于已实现,因此您可以传递的工作数量非常有限,并且以可移植的方式找到此限制并非易事。您必须调用sysconf(_SC_AIO_LISTIO_MAX),这可能会失败,在这种情况下,您可以使用不一定定义的AIO_LISTIO_MAX定义,但是您可以使用2(已定义为保证受支持)。

至于使用posix AIO的实际应用程序,您可以看一看lighttpd(lighty),它在引入支持时也会发布性能评估。

到目前为止,大多数posix平台都支持posix AIO(Linux,BSD,Solaris,AIX,tru64)。 Windows通过其重叠的文件I / O支持它。我的理解是,只有Solaris,Windows和Linux才真正支持异步。文件I / O一直到驱动程序,而其他OS则模拟异步。具有内核线程的I / O。 Linux是个例外,它在glibc中的posix AIO实现模拟了用户级线程的异步操作,而其本机异步I / O接口(io_submit()等)一直到驱动程序都是异步的,前提是驱动程序支持它。

我相信在OS中,不为任何fd支持posix AIO而是将其限制为常规文件是相当普遍的。


网络I / O并不是AIO的优先事项,因为编写POSIX网络服务器的每个人都使用基于事件的非阻塞方法。 旧式的Java"数十亿个阻塞线程"方法令人毛骨悚然。

磁盘写I / O已经被缓冲,可以使用posix_fadvise之类的功能将磁盘读I / O预取到缓冲区中。 这将直接的,无缓冲的磁盘I / O留作AIO的唯一有用目的。

直接,无缓冲的I / O仅对事务数据库真正有用,并且那些数据库倾向于编写自己的线程或进程来管理其磁盘I / O。

因此,最后使POSIX AIO失去了任何有用的作用。 不要使用它。


libtorrent开发人员提供了有关此问题的报告:http://blog.libtorrent.org/2012/10/asynchronous-disk-io/


有aio_write-在glibc中实现; 第一次调用aio_read或aio_write函数会产生许多用户模式线程,对该线程发出aio_write或aio_read post请求,该线程会进行pread / pwrite操作,完成后,答案将回传到被阻止的调用线程中。

它们也是"真正的" aio-内核级别支持(需要libaio,请参见io_submit调用http://linux.die.net/man/2/io_submit); 为此也需要O_DIRECT(可能并非所有文件系统都支持O_DIRECT,但主要的文件系统都支持它)

看这里:

http://lse.sourceforge.net/io/aio.html

http://linux.die.net/man/2/io_submit

POSIX AIO和Linux上的libaio之间的区别?


展开全文阅读

相关内容