异步AIO的研究
2016-01-09 19:23
453 查看
首先声明一下epoll+nonblock从宏观角度可以叫做全异步,但从微观的角度来看还是同步的IO。只是在数据到达后得到系统通知,然后同步执行recv取回数据,没有iowait。
真正的异步IO(下面会统一叫做AIO)应该像Windows IOCP一样,传入文件句柄,缓存区,尺寸等参数和一个函数指针,当操作系统真正完成了IO操作,再执行对应的函数。
实际上对于socket来说,epoll已经是最高效的模型了,虽然比AIO多一次recv系统调用,但总体来看没有任何IO等待,效率很高。而且epoll是天然的reactor模型,程序实现更容易。AIO如windows的IOCP,是异步回调的方式,开发难度很高。
为什么还是需要AIO呢,原因是文件句柄跟socket完全不同,它总是处于可读状态。不能使用epoll+nonblock来实现异步化。如果在一个epoll的全异步Server中,要读写文件那必须得使用AIO。下面说下AIO的几种实现方案。
gcc遵循posix标准实现了AIO。头文件为 <aio.h>,支持FreeBSD/Linux。是通过阻塞IO+线程池来实现的。主要的几个函数是aio_read/aio_write/aio_return。
优点:支持平台多,兼容性好,无需依赖第三方库,阻塞IO可以利用到操作系统的PageCache。
缺点:据说有一些bug和陷阱,一直未解决。不过这个都是网上文章中讲的,gcc发展这么多年,不至于还有遗留bug吧。这里有待测试。
由操作系统内核提供的AIO,头文件为<linux/aio_abi.h>。Native Aio是真正的AIO,完全非阻塞异步的,而不是用阻塞IO和线程池模拟。主要的几个系统调用为io_submit/io_setup/io_getevents。
优点:由操作系统提供,读写操作可以直接投递到硬件,不会浪费CPU。
缺点:仅支持Linux,必须使用DirectIO,所以无法利用到操作系统的PageCache。对于写文件来说native aio的作用不大,应为本身写文件就是先写到PageCache上,直接返回,没有IO等待。
libev的作者开发的AIO实现,与gcc aio类似也是使用阻塞IO+线程池实现的。优点与缺点参见上面。它与gcc aio的不同之处,代码更简洁,所以bug少更安全稳定。但这是一个第三方库,你的代码需要依赖libeio。
如果你的程序读写的文件很大,随即性强,这样PageCache的命中率低,那可以选择Native AIO,降低CPU使用率。
如果读写的文件很小,而且是固定的一些文件,这样PageCache的命中率高,可以选择gcc aio或者libeio。
FROM: http://rango.swoole.com/archives/282
真正的异步IO(下面会统一叫做AIO)应该像Windows IOCP一样,传入文件句柄,缓存区,尺寸等参数和一个函数指针,当操作系统真正完成了IO操作,再执行对应的函数。
实际上对于socket来说,epoll已经是最高效的模型了,虽然比AIO多一次recv系统调用,但总体来看没有任何IO等待,效率很高。而且epoll是天然的reactor模型,程序实现更容易。AIO如windows的IOCP,是异步回调的方式,开发难度很高。
为什么还是需要AIO呢,原因是文件句柄跟socket完全不同,它总是处于可读状态。不能使用epoll+nonblock来实现异步化。如果在一个epoll的全异步Server中,要读写文件那必须得使用AIO。下面说下AIO的几种实现方案。
gcc AIO
gcc遵循posix标准实现了AIO。头文件为 <aio.h>,支持FreeBSD/Linux。是通过阻塞IO+线程池来实现的。主要的几个函数是aio_read/aio_write/aio_return。优点:支持平台多,兼容性好,无需依赖第三方库,阻塞IO可以利用到操作系统的PageCache。
缺点:据说有一些bug和陷阱,一直未解决。不过这个都是网上文章中讲的,gcc发展这么多年,不至于还有遗留bug吧。这里有待测试。
Linux Native Aio
由操作系统内核提供的AIO,头文件为<linux/aio_abi.h>。Native Aio是真正的AIO,完全非阻塞异步的,而不是用阻塞IO和线程池模拟。主要的几个系统调用为io_submit/io_setup/io_getevents。优点:由操作系统提供,读写操作可以直接投递到硬件,不会浪费CPU。
缺点:仅支持Linux,必须使用DirectIO,所以无法利用到操作系统的PageCache。对于写文件来说native aio的作用不大,应为本身写文件就是先写到PageCache上,直接返回,没有IO等待。
Libeio
libev的作者开发的AIO实现,与gcc aio类似也是使用阻塞IO+线程池实现的。优点与缺点参见上面。它与gcc aio的不同之处,代码更简洁,所以bug少更安全稳定。但这是一个第三方库,你的代码需要依赖libeio。
总结
如果你的程序读写的文件很大,随即性强,这样PageCache的命中率低,那可以选择Native AIO,降低CPU使用率。如果读写的文件很小,而且是固定的一些文件,这样PageCache的命中率高,可以选择gcc aio或者libeio。
FROM: http://rango.swoole.com/archives/282
相关文章推荐
- scu - 3254 - Rain and Fgj(最小点权割)
- 蓝牙写入出错,error isError Domain=CBATTErrorDomain Code=114 "Unknown ATT error."
- rails书籍展示添加游客评论
- Wait--使用sys.dm_io_virtual_file_stats来查看IO延迟
- 从notify-wait模式说去
- Contains Duplicate II leetcode
- 【转载】Kafka High Availability
- Contains Duplicate leetcode
- Codeforces Round #180 (Div. 2) B. Sail 贪心
- 职责链模式(Chain of Responsibility)
- offsetof与container_of宏[总结]
- Codeforces Round #338 (Div. 2) B. Longtail Hedgehog
- Codef b125 orces 615B Longtail Hedgehog 【dp】
- UVa 474 - Heads / Tails Probability
- mailx定时任务不能执行
- B. Longtail Hedgehog【记忆化搜索】
- [CodeForces 615B]Longtail Hedgehog[DP]
- Binder与Service 通信机制详解四 (源码分析AIDL工作机制)
- Codeforces Round #338 (Div. 2)B. Longtail Hedgehog(贪心+dp)
- UltraISO软碟通怎么装系统 UltraISO软碟通不用U盘装系统图文教程