select/poll/epoll简介
epoll和select都能够提供多路I/O复用的解决方案,在现在的Linux内核中都能够支持,其中epoll是Linux特有,而select则应该是POSIX所规定,一般操作系统均有实现
select:
select本质是通过设置或者检查存放fd标志位的数据结构进行下一步的处理。这样所带来的缺点是:
1.单个进程可监视的fd数量被限制,即能监听端口的大小有限。
一般来说这个数目和内存的关系很大,具体数目可以cat /proc/sys/fs/file-max观察。32位机默认1024个。64位机默认2048个。
2.对socket进行扫描是线性的,采用轮询的方式,效率较低。
当套接字比较多的时候,每次select()系统调用都要通过遍历FD_SET SIZE个socket来完成调度,不管哪个socket都是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给某个套接字注册某个回调函数,当他们活跃时,自动完成相关操作,那就避免了轮询,这正是epoll和poll所作的。
3.维护一个用来存放大量fd的数据结构,这样会使得用户空间和内核空间在传递该结构时复制开销大
poll:
poll本质上和select没有区别,它将用户传入的数组拷贝到内核空间,然后查询每个fd对应的状态,如果设备就绪则在设备等待队列中加入一项并继续遍历啊,如果遍历完所有的fd后没有发现就绪设备,则挂起当前线程,直到设备就绪或者主动超时,被唤醒后它又要再次遍历fd,这个过程经历了无数的遍历。
它没有最大连接数的限制,原因是它是基于链表来存储的,但是同样有一个缺点:
1.大量的fd的数组被整体复制于用户态和内核态空间之间,而不管这样的复制是不是有意义。
2.poll还有一个缺点是“水平触发”,如果报告了fd之后没有被处理,那么下次poll时会再次报告该fd。
epoll:
epoll有epoll LT和epoll ET两种触发模式,LT是默认的模式,ET是“高速”模式。LT模式下,只要这个fd还有数据可读,每次epoll_wait都会返回它的事件,提醒用户程序去操作,而在ET(边缘触发)模式中,它只会提示一次,直到下次再有数据流入之前都不会再提示了,无论fd是否还有数据可读。再ET模式下,read一个fd的时候一定要把它的buffer读完,也就是一直读到read的返回值小于请求值,或者遇到EAGAIN错误。还有一个特点是epoll使用“事件”的就绪通知方式,通过epoll_ctl注册fd,一旦该fd就绪,内核就会采用类似callback的回调机制激活该fd,epoll_wait便可以接收到通知。
epoll为什么会有epoll ET触发模式?
如果采用epoll LT模式的话,系统中一旦有大量你不需要读写的就绪文件描述符,它们每次调用epoll_wait都会返回,这样会大大降低程序处理自己关心的就绪文件描述符的效率。而采用epoll ET这种边沿触发模式的话,当被监控的文件描述符上有可读写事件发生时,epoll_wait才会通知程序去处理读写。如果这次没有把数据全部读写完,下次调用时,它不会通知你,也就是它只会通知一次,直到该文件描述符上出现第二次可读写事件时才会通知你!!!这种模式比水平触发模式效率高,系统不会充斥大量你不关心的就绪文件描述符
epoll的优点:
1.没有最大并发连接的限制,能打开的FD的上限远大于1024个(1G的内存上能监听月10万个端口);
2.效率提升,不是轮询的方式,不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数;
epoll最大的优点在于它只管“活跃”的连接,跟连接总数无关,因此在实际网络中,epoll的效率就会远远高于select和poll
3.内存拷贝,利用mmap()文件映射内存加速与内核空间消息的传递;epoll使用mmap减少复制开销。
select:
优点:
1.select的可移植性好,在某些Unix系统上不支持poll
2.select对于超时值提供了更好的精度,微妙,而poll是毫秒。
缺点:
1.每次调用select,都需要把fd集合从用户态拷贝到内核态,这个开销在fd很多时,会很大
2.同时每次调用select都需要在内核遍历传递进来的所有fd,这个开销在fd很多时,也会很大。
3.select支持的文件描述符数量少,默认1024
poll:
优点:
1.poll不需要要求开发者计算最大文件描述符加一的大小
2.poll在应付大数目的文件描述符的时候速度更快,相比于select
3.它没有最大连接数的限制,原因时基于链表来存储的
缺点:
1.大量的fd的数组被整体复制于用户态和内核态地址空间,而不管这样的复制是不是有意义;
2.与select一样,poll返回后,需要轮询fd来获取就绪的描述符,
epoll的优点:
1.支持一个进程打开大数目的socket描述符
相比select,epoll则没有对FD的限制,它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右,具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
2.IO效率不随着FD数目的增加而线性下降
epoll不存在这个问题,它只会对"活跃"的socket进行操作--- 这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么,只有"活跃"的socket才会主动的去调用 callback函数,其他idle状态socket则不会,在这点上,epoll实现了一个"伪"AIO,因为这时候推动力在os内核。在一些 benchmark中,如果所有的socket基本上都是活跃的---比如一个高速LAN环境,epoll并不比select/poll有什么效率,相 反,如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
3.使用mmap加速内核与用户空间的消息传递
这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间,如何避免不必要的内存拷贝就 很重要,在这点上,epoll是通过内核于用户空间mmap同一块内存实现的。
总结:
1、表面上看epoll的性能最好,但是在连接数少并且连接都十分活跃的情况下,select和poll的性能可能比epoll好,毕竟epoll的通知机制需要很多函数回调。
2、select低效是因为每次它都需要轮询。但低效也是相对的,视情况而定,也可通过良好的设计改善