epoll机制详解
大牛的详解
epoll详解
- 什么是epoll?
- epoll是为处理大批量句柄而作了改进的poll, 是性能最好的多路I/O就绪通知方法;
- 只有三个系统调用: epoll_create, epoll_ctl, epoll_wait;
- epoll_ctl - epoll的事件注册函数,它不同于select()是在监听事件时告诉内核要监听什么类型的事件,而是在这里先注册要监听的事件类型;
- epoll的工作原理
- epoll同样只告知那些就绪的文件描述符,而且当我们调用epoll_wait()获得就绪文件描述符时,返回的不是实际的描述符,而是一个代表就绪描述符数量的值;
- 你只需要去epoll指定的一个数组中依次取得相应数量的文件描述符即可,这里也使用了内存映射(mmap)技术,这样便彻底省掉了这些文件描述符在系统调用时复制的开销;
- 另一个本质的改进在于epoll采用基于事件的就绪通知方式;
- 在select/poll中,进程只有在调用一定的方法后,内核才对所有监视的文件描述符进行扫描;
- 而epoll事先通过epoll_ctl()来注册一个文件描述符,一旦基于某个文件描述符就绪时,内核会采用类似callback的回调机制,迅速激活这个文件描述符,当进程调用epoll_wait()时便得到通知;
- epoll的两种工作方式
- 水平触发(LT)
- 相当于速度比较快的poll;
- LT(level triggered)是epoll缺省的工作方式,并且同时支持block和no-block socket.在这种做法中,内核告诉你一个文件描述符是否就绪了,然后你可以对这个就绪的fd进行IO操作;
- 如果你不作任何操作,内核还是会继续通知你的,所以,这种模式编程出错误可能性要小一点;
- 传统的select/poll都是这种模型的代表.
- 边缘触发(ET)
- 用了EPOLLET标志;
- 相当于非阻塞的读;
- ET (edge-triggered)是高速工作方式,只支持no-block socket,它效率要比LT更高;
- ET与LT的区别在于,当一个新的事件到来时,ET模式下当然可以从epoll_wait调用中获取到这个事件,可是如果这次没有把这个事件对应的套接字缓冲区处理完,在这个套接字中没有新的事件再次到来时,在ET模式下是无法再次从epoll_wait调用中获取这个事件的;
- 而LT模式正好相反,只要一个事件对应的套接字缓冲区还有数据,就总能从epoll_wait中获取这个事件;
- LT模式下开发基于epoll的应用要简单些,不太容易出错。而在ET模式下事件发生时,如果没有彻底地将缓冲区数据处理完,则会导致缓冲区中的用户请求得不到响应;
epoll的优点
- 支持一个进程打开大数目的socket描述符(FD);
- select 最不能忍受的是一个进程所打开的FD是有一定限制的,由FD_SETSIZE设置,默认值是2048;
- 重新编译内核解决这个问题, 或者利用多进程解决这个问题(Apache方案);
- epoll则没有这个限制,它所支持的FD上限是最大可以打开文件的数目, 这个数字一般远大于2048, 1G的内存上是10W左右;
- IO效率不随FD数目增加而线性下降;
- 传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合,性能会线性下降;
- 不过由于网络延时,任一时间只有部分的socket是"活跃"的,但是select/poll每次调用都会线性扫描全部的集合,导致效率呈现线性下降;
- epoll不存在这个问题,它只会对"活跃"的socket进行操作(内核实现的原因);
- 这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的;
- 只有"活跃"的socket才会主动的去调用 callback函数,其他idle状态socket则不会;
- epoll实现了一个"伪AIO,因为这时候推动力在os内核;
- 在一些 benchmark中,如果所有的socket基本上都是活跃的;
- epoll并不比select/poll有什么效率,相反,如果过多使用epoll_ctl,效率相比还有稍微的下降;
- 使用mmap加速内核与用户空间的消息传递;
- 这点实际上涉及到epoll的具体实现了;
- 无论是select,poll还是epoll都需要内核把FD消息通知给用户空间,如何避免不必要的内存拷贝就很重要,在这点上,epoll是通过内核于用户空间mmap同一块内存实现的;
- epoll是一种IO多路复用技术,可以非常高效的处理数以百万计的socket句柄;
- 因为select/poll每次调用时都要传递你所要监控的所有socket给select/poll系统调用,这意味着需要将用户态的socket列表copy到内核态,如果以万计的句柄会导致每次都要copy几十几百KB的内存到内核态,非常低效;
- epoll_wait却不用传递socket句柄给内核,因为内核已经在epoll_ctl中拿到了要监控的句柄列表;
- epoll还维护了一个双链表,用户存储发生的事件;
- 当epoll_wait调用时,仅仅观察这个list链表里有没有数据即eptime项即可;
- 有数据就返回,没有数据就sleep,等到timeout时间到后即使链表没数据也返回;
- 这个准备就绪list链表是怎么维护的呢?
- 当我们执行epoll_ctl时,除了把socket放到epoll文件系统里file对象对应的红黑树上之外;
- 还会给内核中断处理程序注册一个回调函数,告诉内核,如果这个句柄的中断到了,就把它放到准备就绪list链表里;
- 一颗红黑树,一张准备就绪句柄链表,少量的内核cache,就帮我们解决了大并发下的socket处理问题;
- 执行epoll_create时,创建了红黑树和就绪链表;
- 执行epoll_ctl时,如果增加socket句柄,则检查在红黑树中是否存在,存在立即返回,不存在则添加到树干上,然后向内核注册回调函数,用于当中断事件来临时向准备就绪链表中插入数据;
- 执行epoll_wait时立刻返回准备就绪链表里的数据即可;
posted @
2018-09-07 16:03
coding-for-self
阅读(
4573)
评论()
编辑
收藏
举报