zoukankan      html  css  js  c++  java
  • linux AIO (异步IO) 那点事儿 [转]

    本文为原创文章,出自http://cnodejs.org,转载请注明出处和作者
    作者:爱多
    原文:http://cnodejs.org/blog/?p=2426

            在高性能的服务器编程中,IO 模型理所当然的是重中之重,需要谨慎选型的,对于网络套接字,我们可以采用epoll 的方式来轮询,尽管epoll也有一些缺陷,但总体来说还是很高效的,尤其来大量套接字的场景下;但对于Regular File 来说,是不能够用采用 poll/epoll 的,即O_NOBLOCK 方式对于传统文件句柄是无效的,也就是说我们的 open ,read, mkdir 之类的Regular File操作必定会导致阻塞.在多线程、多进程模型中,可以选择以同步阻塞的方式来进行IO操作,任务调度由操作系统来保证公平性,但在单进程/线程模型中,以nodejs 为例 ,假如 我们需要在一个用户请求中处理10个文件:

    1
    2
    3
    4
    5
    function fun() {
     fs.readFileSync();
     fs.readFileSync();
     
     }

    这时候进程至少会阻塞10次,而这可能会导致其他的上千个用户请求得不到处理,这当然是不能接受的.

    Linux AIO 早就被提上议程,目前比较知名的有 Glibc 的 AIO   与 Kernel Native AIO
    Glibc AIO: http://www.ibm.com/developerworks/linux/library/l-async/
    Kernel Native AIO: http://lse.sourceforge.net/io/aio.html

    我们用Glibc 的AIO 做个小实验,写一个简单的程序:异步方式读取一个文件,并注册异步回调函数:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    int  main()
    {
    struct aiocb my_aiocb;
    fd = open("file.txt", O_RDONLY);
    ...
    my_aiocb.aio_sigevent.sigev_notify_function = aio_completion_handler;
    ret = aio_read(&my_aiocb);
    write(1, "caller thread\n", 14);
    sleep(5);
    }
     
    void aio_completion_handler(sigval_t sigval)
    {
    write(1, "callback\n", 9);
    struct aiocb *req;
    ...
    req = (struct aiocb *)sigval.sival_ptr;
    printf("data: %s\n" ,req->aio_buf);
    return;
    }

    我们用 strace 来跟踪调用,得到以下结果 (只保留主要语句):

    23908 open(“file.txt”, O_RDONLY)        = 3
    23908 clone(…) = 23909
    23908 write(1, “caller thread\n”, 14)   = 14
    23908 nanosleep({5, 0},  <unfinished …>

    23909 pread(3, “hello, world\n”, 1024, 0) = 13
    23909 clone(..)= 23910
    23909 futex(0x3d3a4082a4, FUTEX_WAIT_PRIVATE, 1, {0, 999942000} <unfinished …>

    23910 write(1, “callback\n”, 9)         = 9
    23910 write(1, “data: hello, world\n”, 19) = 19
    23910 write(1, “\n”, 1)                 = 1
    23910 _exit(0)                          = ?
    23909 <… futex resumed> )             = -1 ETIMEDOUT (Connection timed out)
    23909 futex(0x3d3a408200, FUTEX_WAKE_PRIVATE, 1) = 0
    23909 _exit(0)                          = ?
    23908 <… nanosleep resumed> {5, 0})   = 0
    23908 exit_group(0)                     = ?

    在Glibc AIO 的实现中, 用多线程同步来模拟 异步IO ,以上述代码为例,它牵涉了3个线程,
    主线程(23908)新建 一个线程(23909)来调用 阻塞的pread函数,当pread返回时,又创建了一个线程(23910)来执行我们预设的异步回调函数, 23909 等待23910结束返回,然后23909也结束执行..

    实际上,为了避免线程的频繁创建、销毁,当有多个请求时,Glibc AIO 会使用线程池,但以上原理是不会变的,尤其要注意的是:我们的回调函数是在一个单独线程中执行的.
    Glibc AIO 广受非议,存在一些难以忍受的缺陷和bug,饱受诟病,是极不推荐使用的.
    详见:http://davmac.org/davpage/linux/async-io.html

    在Linux 2.6.22+ 系统上,还有一种 Kernel AIO 的实现,与Glibc 的多线程模拟不同 ,它是真正的做到内核的异步通知,比如在较新版本的Nginx 服务器上,已经添加了AIO方式 的支持.

    http://wiki.nginx.org/HttpCoreModule
    aio
    syntax: aio [on|off|sendfile]
    default: off
    context: http, server, location
    This directive is usable as of Linux kernel 2.6.22. For Linux it is required to use directio, this automatically disables sendfile support.

    location /video {
    aio on;
    directio 512;
    output_buffers 1 128k;
    }

    听起来Kernel Native AIO 几乎提供了近乎完美的异步方式,但如果你对它抱有太高期望的话,你会再一次感到失望.

    目前的Kernel AIO 仅支持 O_DIRECT 方式来对磁盘读写,这意味着,你无法利用系统的缓存,同时它要求读写的的大小和偏移要以区块的方式对齐,参考nginx 的作者 Igor Sysoev 的评论: http://forum.nginx.org/read.php?2,113524,113587#msg-113587

    nginx supports file AIO only in 0.8.11+, but the file AIO is functional
    on FreeBSD only. On Linux AIO is supported by nginx only on kerenl
    2.6.22+ (although, CentOS 5.5 has backported the required AIO features).
    Anyway, on Linux AIO works only if file offset and size are aligned
    to a disk block size (usually 512 bytes) and this data can not be cached
    in OS VM cache (Linux AIO requires DIRECTIO that bypass OS VM cache).
    I believe a cause of so strange AIO implementaion is that AIO in Linux
    was developed mainly for databases by Oracle and IBM.

    同时注意上面的橙色字部分,启用AIO 就会关闭sendfile -这是显而易见的,当你用Nginx作为静态服务器,你要么选择以AIO 读取文件到用户缓冲区,然后发送到套接口,要么直接调用sendfile发送到套接口,sendfile 虽然会导致短暂的阻塞,但开启AIO 却无法充分的利用缓存,也丧失了零拷贝的特征 ;当你用Nginx作为动态服务器,比如 fastcgi + php 时,这时php脚本中文件的读写是由php 的 文件接口来操作的,这时候是多进程+同步阻塞模型,和文件异步模式扯不上关系的.

    所以现在Linux 上,没有比较完美的异步文件IO 方案,这时候苦逼程序员的价值就充分体现出来了,libev 的作者 Marc Alexander Lehmann 老大就重新实现了一个AIO library :

    http://software.schmorp.de/pkg/libeio.html

    其实它还是采用线程池+同步模拟出来的,和Glibc 的 AIO 比较像,用作者的话说,这个库相比与Glibc 的实现,开销更小,bug更少(不然重新造个轮子还有毛意义呢?反正我是信了) ,不过这个轮子的代码可读性实在不敢恭维,Marc 老大自己也说了:Currently in BETA! Its code, documentation, integration and portability quality is currently below that of libev, but should soon be ready for use in production environments.

    (其实libev代码和文档可读性也不咋地,貌似驱动内核搞多了都这样?)好吧,腹诽完了,我们还是阅读下它的源码 ,来稍微分析一下它的原理:

    (这个文章的流程图还是蛮靠谱的:http://cnodejs.org/blog/?p=244  ,此处更详细的补充一下下)

    int eio_init (void (*want_poll)(void), void (*done_poll)(void))

    初始化时设定两个回调函数,它有两个全局的数据结构 : req 存放请求队列,res 存放已经完成的队列 当我,当你提交一个异步请求时(eio_submit),其实是放入req队列中,然后向线程池中处于信号等待的线程发送信号量(如果线程池中没有线程就创建一个),获得信号的线程会执行如下代码:

    1
    2
    3
    4
    5
    6
    ETP_EXECUTE (self, req);
    X_LOCK (reslock);
    ++npending;
    if (!reqq_push (&res_queue, req) && want_poll_cb)
    want_poll_cb ();
    X_UNLOCK (reslock);

    ETP_EXECUTE 就是实际的阻塞调用,比如read,open,,sendfile之类的,当函数返回时,表明操作完成,此时加锁方式向完成队列添加一项 ,然后调用 want_pool ,这个函数是我们eio_init时候设置的,然后释放锁。

    注意:每次完成任务时,都要调用want_poll ,所以这个函数应该是线程安全且尽量短促,实际上我们为了避免陷入多线程的泥淖,我们往往配合eio使用事件轮询机制,比如:我们创建一对管道,我们把“读”端的管道加入 epoll 监控结构中,want_poll 函向“写”端管道写数入一个字节或字长 ,所以当下次epoll_wait 返回时,我们会执行 “读” 端管道的 回调函数,类似如下:

    1
    2
    3
    4
    void r_pipe_cb(){
    ...
    eio_poll();
    }

    在eio_poll 中 有类似以下代码:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    for(;;){
    X_LOCK (reslock);
    req = reqq_shift (&res_queue);
    if (req){
    if (!res_queue.size && done_poll_cb)
    done_poll_cb ();
    }
    X_UNLOCK (reslock);
    res = ETP_FINISH (req);
    ...
    if(empty) break;
     
    }

    eio_poll 函数就是从完成队列res 依次shift ,依次执行我们的回调函数(ETP_FINISH 就是执行用户回调),在取出完成队列的最后一项但还没有执行用户回调之前,调用我们设定的done_poll ,对res队列的操作当然也是加锁的,注意此时我们自定义的异步回调函数是在我们的主线程中执行的!这才是我们的最终目的!

    在eio 线程池中,默认最多4个线程,在高性能的程序中,过多的进程/线程往往也是一个瓶颈,
    寄存器的进出栈还是其次,进程虚存地址切换、各级cache 的miss ,这才是最昂贵的,所以,最理想的情形就是:有几个cpu ,就有同样数目的active  线程/进程,但因为io线程往往会陷入sleep模式,所以,还是需要额外的待切换的线程的,作为经验法则,线程池的数量最好是cpu 的数目 X 2(参见windows 核心编程 IOCP卷).

    libeio 虽不完美,但目前还是将就着用用吧 …

  • 相关阅读:
    eclipse报错 : One or more constraints have not been satisfied.
    关于一个计算机同时装两个jdk对应两个eclipse
    开发测试类2
    工作中测试类1
    Spring 读取classpath下的文件存到map里面
    CentOS6下安装JDK并且部署tomcat容器
    ConOS安装mysql5.7 及简单配置
    用sqlyog迁移mysql数据库
    FindBugs缺陷库
    使用NumberPicker定制自己喜欢的Date&TimePicker
  • 原文地址:https://www.cnblogs.com/feisky/p/2377530.html
Copyright © 2011-2022 走看看