请教 epoll和多线程问题

qinyd

问2个select/epoll和多线程的问题

1. select 是进程限定fd数，还是线程限定fd数.
   假如我创建1025个线程，每个线程管一个TCP连接。用select是否可以
   
2.
   很多描述epoll优点的，都是基于 使用一个线程epoll所有TCP连接 这种情况。
   我的程序是使用多线程，一个线程epoll一个TCP连接。这样 epoll相对select还有没有优势

alexhappy

1，不是太清楚你的意思，不过不管怎么说select默认是1024个文件描述符，多了就地去改头文件然后重新编译。。。。
2，一个线程一个epoll？然后一个epoll一个连接？我从来没有听说过这中模式的。。。。不过，a,多线程肯定是比单线程耗资源；b，在每个线程里用epoll的话跟不用它有什么区别？！那还不如直接拿多线程跟select比，select的性能比多线程的要好。。。。。

chenzhanyiczy

select的大小不是跟进程或线程有关的，一般默认最多是1024个文件描述符，当然你可以修改FD_??SIZE参数，重新编译内核

一个线程epoll一个TCP连接?那你的服务器会叫苦的
一般的模型是多进程+epoll+线程池+异步

redor

原帖由 qinyd 于 2008-10-22 11:21 发表
问2个select/epoll和多线程的问题

1. select 是进程限定fd数，还是线程限定fd数.
   假如我创建1025个线程，每个线程管一个TCP连接。用select是否可以
   
2.
   很多描述epoll优点的，都是基于 使用一 ...

描数字的限制可以通过setrlimit() 实现的, 里边有RLIMIT_NOFILE是用来设置描数字的限制的, linux系统上应该是可以设置最多65536个.

epoll对于select好处是描述比较多的时候优势比较明显, epoll是不需要循环这个sets检查, epoll实现是通过描数字有IO异动的时候检查描数字对应的读写buffer区的大小, 写buffer小于某个阀值的时候标记为可写, 读buffer区大于某个阀值的时候标记可读, 只要你执行epoll_wait() 的时候所有可读写的描数字队列会返回给你.
这样就相当于一个异步的读写通知, 不需要等待.

redor

原帖由 chenzhanyiczy 于 2008-10-22 12:35 发表
select的大小不是跟进程或线程有关的，一般默认最多是1024个文件描述符，当然你可以修改FD_??SIZE参数，重新编译内核

一个线程epoll一个TCP连接?那你的服务器会叫苦的
一般的模型是多进程+epoll+线程池+异步

看来是我理解错了, 呵呵

[ 本帖最后由 redor 于 2008-10-22 17:27 编辑 ]

chenzhanyiczy

原帖由 redor 于 2008-10-22 12:36 发表



老大.... 你这样告诉别人就相当于二把刀了.... 那个描数字多少是不需要编译内核的...

http://blog.chinaunix.net/u/7356/showart_58474.html

redor

原帖由 chenzhanyiczy 于 2008-10-22 13:04 发表



http://blog.chinaunix.net/u/7356/showart_58474.html

这个不是原文.... 原文肯定不是这么写的, 实际操作的时候是不需要重新编译内核的.... 因为实际用的时候一般是通过setrlimit修改描数字最大个数, 所以这种不是很地道的做法最好不要到处宣扬... 不然初学者会误认为只能这样做.

zhoubug

原帖由 redor 于 2008-10-22 13:54 发表



这个不是原文.... 原文肯定不是这么写的, 实际操作的时候是不需要重新编译内核的.... 因为实际用的时候一般是通过setrlimit修改描数字最大个数, 所以这种不是很地道的做法最好不要到处宣扬... 不然初学者 ...

我想你的理解是错误的，setrlimit or ulimit -n 是可以改变你进程所可以打开的最大文件句柄数，但并不是说，他们都可以被放到fd_set中进行select 的，看下面是它的定义：

/* fd_set for select and pselect.  */ typedef struct   {     /* XPG4.2 requires this member name.  Otherwise avoid the name        from the global namespace.  */ #ifdef __USE_XOPEN     __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS]; # define __FDS_BITS(set) ((set)->fds_bits) #else     __fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS]; # define __FDS_BITS(set) ((set)->__fds_bits) #endif   } fd_set;

这仅仅是个数组，而__FD_SETSIZE是在/usr/include/linux/posix_types.h（我的ubuntu 8.04是在这个位置)里定义好的，我们编译自己程序的时候如果不重新定义这个值也就是数组的大小并不会增大，所以说仅仅setrlimit应该不行。

高并发服务器当然还是建议用epoll。

[ 本帖最后由 zhoubug 于 2008-10-22 15:40 编辑 ]

qinyd

没描述清楚，我再描述一下

问题1：
    假如默认maxfd=1024 , 不去改系统任何东西的情况下
    如果我用一个进程/线程处理TCP收发的话(用select)，到1025个连接来，是不是应该就不行了，收发不了？
    如果每有一个TCP连接，我建一个线程处理收发(用select)。到1025个连接来，能不能收发？

    上面问的不对，这样：
    ulimit -n 10000  这里每个进程允许的最大打开描述符改了
    但是 select 装载描述符的数组大小没改，还是1024，没有重新编译内核

    在这样的条件下
    单进程/线程处理TCP收发的话，到1025个连接来就不行
    而每个TCP连接，建一个线程处理收发的话，到1025个连接来就可以
    对不对   

问题2：
    如果每有一个TCP连接，我建一个线程处理收发(用poll 和 用epoll)。当TCP连接数达到几千上万(假如可以)，这时候epoll 对 poll 有没有优势。

    因为我现在接手的程序就是一个线程处理一个TCP收发的。所以我看看 基于现状，怎么改进

[ 本帖最后由 qinyd 于 2008-10-22 16:19 编辑 ]

zhoubug

原帖由 qinyd 于 2008-10-22 14:33 发表
没描述清楚，我再描述一下

问题1：
    假如默认maxfd=1024 , 不去改系统任何东西的情况下
    如果我用一个进程/线程处理TCP收发的话(用select)，到1025个连接来，是不是应该就不行了，收发不了？
    如 ...

如果你不改maxfd你的1025个连接应该是建立不了的，另外你现在的这种改进思路，随便哪个效率差别不大，不好。本来这些机制都是处理多个句柄的事件分发的，你一个对一个，如果你需求不大，就凑合着用哪个都行。