posts - 9, comments - 41, trackbacks - 0, articles - 1536
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

公告

epoll 水平触发 边沿触发

Posted on 2014-09-12 17:17 bw_0927 阅读(...) 评论(...)  编辑 收藏

http://www.cppfans.org/1417.html

http://blog.lucode.net/linux/epoll-tutorial.html

 

现如今,网络通讯中用epoll(linux)和IOCP(windows)几乎是大家津津乐道的东西,不为别的,就因为高效,所以大家喜欢用。IOCP的基础东西已经讲过了,可翻阅《IOCP浅析》 《IOCP浅析[二]——IOCP出现的意义和函数接口》.

什么是epoll

epoll是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率,因为它会复用文件描述符集 合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合,另一点原因就是获取事件的时候,它无须遍历整个被侦听的描述符 集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的电平触发 (Level Triggered)外,还提供了边沿触发(Edge Triggered),这就使得用户空间程序有可能缓存IO状态,减少epoll_wait/epoll_pwait的调用,提高应用程序效率。Linux2.6内核中对/dev/epoll设备的访问的封装(system epoll)。

这个使我们开发网络应用程序更加简单,并且更加高效。

为什么要使用epoll?

同样,我们在linux系统下,影响效率的依然是I/O操作,linux提供给我们select/poll/epoll等多路复用I/O方式(kqueue暂时没研究过),为什么我们对epoll情有独钟呢?原因如下:

1.文件描述符数量的对比。

epoll并没有fd(文件描述符)的上限,它只跟系统内存有关,我的2G的ubuntu下查看是20480个,轻松支持20W个fd。可使用如下命令查看:

cat /proc/sys/fs/file-max

再来看select/poll,有一个限定的fd的数量,linux/posix_types.h头文件中

#define __FD_SETSIZE    1024

2.效率对比。

当然了,你可以修改上述值,然后重新编译内核,然后再次写代码,这也是没问题的,不过我先说说select/poll的机制,估计你马上会作废上面修改枚举值的想法。

select/poll会因为监听fd的数量而导致效率低下,因为它是轮询所有fd,有数据就处理,没数据就跳过,所以fd的数量会降低效率;而epoll只处理就绪的fd,它有一个就绪设备的队列,每次只轮询该队列的数据,然后进行处理。(先简单讲一下,第二篇还会详细讲解)

3.内存处理方式对比。

不管是哪种I/O机制,都无法避免fd在操作过程中拷贝的问题,而epoll使用了mmap(是指文件/对象的内存映射,被映射到多个内存页上),所以同一块内存就可以避免这个问题。

btw:TCP/IP协议栈使用内存池管理sk_buff结构,你还可以通过修改内存池pool的大小,毕竟linux支持各种微调内核。

epoll的工作方式

epoll分为两种工作方式LT和ET。

LT(level triggered) 是默认/缺省的工作方式,同时支持 block和no_block socket。这种工作方式下,内核会通知你一个fd是否就绪,然后才可以对这个就绪的fd进行I/O操作。就算你没有任何操作,系统还是会继续提示fd已经就绪,不过这种工作方式出错会比较小,传统的select/poll就是这种工作方式的代表。

ET(edge-triggered) 是高速工作方式,仅支持no_block socket,这种工作方式下,当fd从未就绪变为就绪时,内核会通知fd已经就绪,并且内核认为你知道该fd已经就绪,不会再次通知了,除非因为某些操作导致fd就绪状态发生变化。如果一直不对这个fd进行I/O操作,导致fd变为未就绪时,内核同样不会发送更多的通知,因为only once。所以这种方式下,出错率比较高,需要增加一些检测程序。

LT可以理解为水平触发,只要有数据可以读,不管怎样都会通知。而ET为边缘触发,只有状态发生变化时才会通知,可以理解为电平变化

如何使用epoll?

使用epoll很简单,只需要

#include <sys/epoll.h>

有三个关键函数:

int epoll_create(int size);

int epoll_ctl(int epfd, int op, int fd, struct epoll_events* event);

int epoll_wait(int epfd, struct epoll_event* events, int maxevents, int timeout);

当然了,不要忘记关闭函数.

 

============分割线==============

这篇就讲到这里了,下面两篇主要是函数介绍,效率分析,例子。

转载请注明:C++爱好者博客 » 浅析epoll-为何多路复用I/O要使用epoll

前一篇大致讲了一下epoll是个什么东西,优点等内容,这篇延续上一篇的内容,主要是分析epoll的函数,epoll高性能的深入分析。

epoll的三大函数

1.创建epoll fd函数

int epoll_create(int size);

epoll_create()创建一个epoll的事例,通知内核需要监听size个fd。size指的并不是最大的后备存储设备,而是衡量内核内部结构大小的一个提示。当创建成功后,会占用一个fd,所以记得在使用完之后调用close(),否则fd可能会被耗尽。

Note:自从Linux2.6.8版本以后,size值其实是没什么用的,不过要大于0,因为内核可以动态的分配大小,所以不需要size这个提示了。

创建还有另外一个函数

int epoll_create1(int flag);

这个函数是在linux 2.6.27中加入的,当你在看陈硕的muduo时可以看到这个函数,其实它和epoll_create差不多,不同的是epoll_create1函数的参数是flag,当flag是0时,表示和epoll_create函数完全一样,不需要size的提示了。

当flag = EPOLL_CLOEXEC,创建的epfd会设置FD_CLOEXEC

当flag = EPOLL_NONBLOCK,创建的epfd会设置为非阻塞

一般用法都是使用EPOLL_CLOEXEC.

Note:关于FD_CLOEXEC,现在网上好多都说的有点问题,我翻阅了一些资料,请教了一些人,大约明白它的意思了。

它是fd的一个标识说明,用来设置文件close-on-exec状态的。当close-on-exec状态为0时,调用exec时,fd不会被关闭;状态非零时则被关闭,这样做可以防止fd泄露给执行exec后的进程。关于exec的用法,大家可以去自己查阅下,或者直接man exec。

2.epoll事件的注册函数

int epoll_ctl(int epfd, int op, int fd, struct epoll_event* event);

select是在监听时告诉内核要监听的事件,而epoll_ctl是先注册需要监听的事件。

第一个参数epfd,为epoll_create返回的的epoll fd。

第二个参数op表示操作值。有三个操作类型,

EPOLL_CTL_ADD  // 注册目标fd到epfd中,同时关联内部event到fd上

EPOLL_CTL_MOD // 修改已经注册到fd的监听事件

EPOLL_CTL_DEL // 从epfd中删除/移除已注册的fd,event可以被忽略,也可以为NULL

第三个参数fd表示需要监听的fd。

第四个参数event表示需要监听的事件。

typedef union epoll_data {
void        *ptr;
int          fd;
uint32_t     u32;
uint64_t     u64;
} epoll_data_t;

struct epoll_event {
uint32_t     events;      /* Epoll events */
epoll_data_t data;        /* User data variable */
};

event参数是一个枚举的集合,可以用” | “来增加事件类型,枚举如下:

EPOLLIN:表示关联的fd可以进行读操作了。
EPOLLOUT:表示关联的fd可以进行写操作了。
EPOLLRDHUP(since Linux 2.6.17):表示套接字关闭了连接,或者关闭了正写一半的连接。
EPOLLPRI:表示关联的fd有紧急优先事件可以进行读操作了。
EPOLLERR:表示关联的fd发生了错误,epoll_wait会一直等待这个事件,所以一般没必要设置这个属性。
EPOLLHUP:表示关联的fd挂起了,epoll_wait会一直等待这个事件,所以一般没必要设置这个属性。
EPOLLET:设置关联的fd为ET的工作方式,epoll的默认工作方式是LT。
EPOLLONESHOT (since Linux 2.6.2):设置关联的fd为one-shot的工作方式。表示只监听一次事件,如果要再次监听,需要把socket放入到epoll队列中。

3.epoll等待事件函数

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
int epoll_pwait(int epfd, struct epoll_event *events, int maxevents, int timeout,  const sigset_t *sigmask);

上面两个函数的参数含义:

第一个参数:表示epoll_wait等待epfd上的事件

第二个参数:events指针携带有epoll_data_t数据

第三个参数:maxevents告诉内核events有多大,该值必须大于0

第四个参数:timeout表示超时时间(单位:毫秒)

epoll_pwait(since linux 2.6.19)允许一个应用程序安全的等待,直到fd设备准备就绪,或者捕获到一个信号量。其中sigmask表示要捕获的信号量。

函数如果等待成功,则返回fd的数字;0表示等待fd超时,其他错误号请查看errno

函数到这里就讲完了,下一篇会写一个例子给大家看下这些函数是如何使用的。

 

============

epoll支持水平触发和边缘触发,理论上来说边缘触发性能更高,但是使用更加复杂,因为任何意外的丢失事件都会造成请求处理错误。Nginx就使用了epoll的边缘触发模型。

这里提一下水平触发和边缘触发就绪通知的区别,这两个词来源于计算机硬件设计。它们的区别是只要句柄满足某种状态,水平触发就会发出通知;而只有当句柄状态改变时,边缘触发才会发出通知。例如一个socket经过长时间等待后接收到一段100k的数据,两种触发方式都会向程序发出就绪通知。假设程序从这个socket中读取了50k数据,并再次调用监听函数,水平触发依然会发出就绪通知,而边缘触发会因为socket“有数据可读”这个状态没有发生变化而不发出通知且陷入长时间的等待。

因此在使用边缘触发的 api 时,要注意每次都要读到 socket返回 EWOULDBLOCK为止否则netstat 的recv-q会持续增加

===============

通常来说,et方式是比较危险的方式,如果要使用et方式,那么,应用程序应该 1、将socket设置为non-blocking方式 2、epoll_wait收到event后,read或write需要读到没有数据为止,write需要写到没有数据为止(对于non-blocking socket来说,EAGAIN通常是无数据可读,无数据可写的返回状态);

我们最近遇到一个问题,就是由于在使用epoll的过程中,缓冲区的数据没有读完,造成后续的通信失败。

表现现象就是,使用netstat -an观察时,这个socket的recv-q值不为0.