epoll和select的优缺

epoll和select的优缺,第1张

  select原理概述   调用select时,会发生以下事情:

  1.从用户空间拷贝fd_set到内核空间;

  2.注册回调函数__pollwait;

  3.遍历所有fd,对全部指定设备做一次poll(这里的poll是一个文件 *** 作,它有两个参数,一个是文件fd本身,一个是当设备尚未就绪时调用的回调函数__pollwait,这个函数把设备自己特有的等待队列传给内核,让内核把当前的进程挂载到其中);

  4.当设备就绪时,设备就会唤醒在自己特有等待队列中的【所有】节点,于是当前进程就获取到了完成的信号。poll文件 *** 作返回的是一组标准的掩码,其中的各个位指示当前的不同的就绪状态(全0为没有任何事件触发),根据mask可对fd_set赋值;

  5.如果所有设备返回的掩码都没有显示任何的事件触发,就去掉回调函数的函数指针,进入有限时的睡眠状态,再恢复和不断做poll,再作有限时的睡眠,直到其中一个设备有事件触发为止。

  6.只要有事件触发,系统调用返回,将fd_set从内核空间拷贝到用户空间,回到用户态,用户就可以对相关的fd作进一步的读或者写 *** 作了。

  epoll原理概述   调用epoll_create时,做了以下事情:

  1.内核帮我们在epoll文件系统里建了个file结点;

  2.在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket;

  3.建立一个list链表,用于存储准备就绪的事件。

  调用epoll_ctl时,做了以下事情:

  1.把socket放到epoll文件系统里file对象对应的红黑树上;

  2.给内核中断处理程序注册一个回调函数,告诉内核,如果这个句柄的中断到了,就把它放到准备就绪list链表里。

  调用epoll_wait时,做了以下事情:

  观察list链表里有没有数据。有数据就返回,没有数据就sleep,等到TImeout时间到后即使链表没数据也返回。而且,通常情况下即使我们要监控百万计的句柄,大多一次也只返回很少量的准备就绪句柄而已,所以,epoll_wait仅需要从内核态copy少量的句柄到用户态而已。

  总结如下:

  一颗红黑树,一张准备就绪句柄链表,少量的内核cache,解决了大并发下的socket处理问题。

  执行epoll_create时,创建了红黑树和就绪链表;

  执行epoll_ctl时,如果增加socket句柄,则检查在红黑树中是否存在,存在立即返回,不存在则添加到树干上,然后向内核注册回调函数,用于当中断事件来临时向准备就绪链表中插入数据;

  执行epoll_wait时立刻返回准备就绪链表里的数据即可。

  两种模式的区别:

  LT模式下,只要一个句柄上的事件一次没有处理完,会在以后调用epoll_wait时重复返回这个句柄,而ET模式仅在第一次返回。

  两种模式的实现:

  当一个socket句柄上有事件时,内核会把该句柄插入上面所说的准备就绪list链表,这时我们调用epoll_wait,会把准备就绪的socket拷贝到用户态内存,然后清空准备就绪list链表,最后,epoll_wait检查这些socket,如果是LT模式,并且这些socket上确实有未处理的事件时,又把该句柄放回到刚刚清空的准备就绪链表。所以,LT模式的句柄,只要它上面还有事件,epoll_wait每次都会返回。

  epoll和select的优缺,epoll和select的优缺   ,第2张

  select的几大缺点:

  (1)每次调用select,都需要把fd集合从用户态拷贝到内核态,这个开销在fd很多时会很大

  (2)同时每次调用select都需要在内核遍历传递进来的所有fd,这个开销在fd很多时也很大

  (3)select支持的文件描述符数量太小了,默认是1024

  epoll

  epoll既然是对select和poll的改进,就应该能避免上述的三个缺点。那epoll都是怎么解决的呢?在此之前,我们先看一下epoll和select和poll的调用接口上的不同,select和poll都只提供了一个函数——select或者poll函数。而epoll提供了三个函数,epoll_create,epoll_ctl和epoll_wait,epoll_create是创建一个epoll句柄;epoll_ctl是注册要监听的事件类型;epoll_wait则是等待事件的产生。

  对于第一个缺点,epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时(在epoll_ctl中指定EPOLL_CTL_ADD),会把所有的fd拷贝进内核,而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。

  对于第二个缺点,epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中,而只在epoll_ctl时把current挂一遍(这一遍必不可少)并为每个fd指定一个回调函数,当设备就绪,唤醒等待队列上的等待者时,就会调用这个回调函数,而这个回调函数会把就绪的fd加入一个就绪链表)。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd(利用schedule_TImeout()实现睡一会,判断一会的效果,和select实现中的第7步是类似的)。

  对于第三个缺点,epoll没有这个限制,它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右,具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

  epoll和select的优缺,epoll和select的优缺   ,第3张

  对比   select缺点:

  最大并发数限制:使用32个整数的32位,即32*32=1024来标识fd,虽然可修改,但是有以下第二点的瓶颈;

  效率低:每次都会线性扫描整个fd_set,集合越大速度越慢;

  内核/用户空间内存拷贝问题。

  epoll的提升:

  本身没有最大并发连接的限制,仅受系统中进程能打开的最大文件数目限制;

  效率提升:只有活跃的socket才会主动的去调用callback函数;

  省去不必要的内存拷贝:epoll通过内核与用户空间mmap同一块内存实现。

  当然,以上的优缺点仅仅是特定场景下的情况:高并发,且任一时间只有少数socket是活跃的。

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/dianzi/2601451.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-08-09
下一篇 2022-08-09

发表评论

登录后才能评论

评论列表(0条)

保存