一、Select:
1. 背景
select最早于1983年出现在4.2BSD中，它通过一个select()系统调用来监视多个FD(File Descriptor, 文件描述符/句柄)的数组。当select()返回后，该数组中就绪的FD便会被内核修改标志位，使得进程可以获得这些FD而进行后续的读写操作。
2. 优点
select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，事实上从现在看来，这也是它所剩不多的优点之一。
3.限制
3.1 Socket数量限制
select的一个缺点在于单个进程所打开的FD是有一定限制的。select的本质是采用32个整数的32位，即存在32*32= 1024的上限，对于那些需要支持的上万连接数目的IM服务器来说显然太少了。
这时候你可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降；
也可以选择多进程的解决方案(传统的Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完美的方案。
常见的使用slect的多进程模型是这样的： 一个进程专门accept，成功后将fd通过unix socket传递给子进程处理，父进程可以根据子进程负载分派。曾经用过1个父进程+4个子进程 承载了超过4000个的负载。
3.2 IO效率随FD数目增加呈线性下降
select另一个致命弱点就是当拥有一个很大的socket集合时，由于网络延时，任一时间只有部分的socket是"活跃"的，但是select每次调用都会线性扫描全部的集合，即select()通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。对于单进程多线程，每个线程处理多个FD的情况，select是不适合的。所有的线程均是从1-32*max进行扫描，每个线程处理的均是一段fd值，这样做导致效率呈现线性下降。
注：在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，这个缺点就不成为缺点了。
此外，包含大量FD的数组被整体复制于用户态和内核的地址空间之间，而不论这些FD是否就绪，它的开销随着FD数量的增加而线性增大。
4.从内核Select的实现看select的限制
这段结合linux内核代码描述，我使用的是2.6.28
select系统调用的代码在fs/Select.c下，
asmlinkage long sys_select(int n, fd_set __user *inp, fd_set __user *outp,
fd_set __user *exp, struct timeval __user *tvp)
{
struct timespec end_time, *to = NULL;
struct timeval tv;
int ret;
if (tvp) {
if (copy_from_user(&tv, tvp, sizeof(tv)))
return -EFAULT;
to = &end_time;
if (poll_select_set_timeout(to,
tv.tv_sec + (tv.tv_usec / USEC_PER_SEC),
(tv.tv_usec % USEC_PER_SEC) * NSEC_PER_USEC))
return -EINVAL;
}
ret = core_sys_select(n, inp, outp, exp, to);
ret = poll_select_copy_remaining(&end_time, tvp, 1, ret);
return ret;
}
前面是从用户控件拷贝各个fd_set到内核空间，接下来的具体工作在core_sys_select中，core_sys_select->do_select,真正的核心内容在do_select里：
int do_select(int n, fd_set_bits *fds, struct timespec *end_time)
{
ktime_t expire, *to = NULL;
struct poll_wqueues table;
poll_table *wait;
int retval, i, timed_out = 0;
unsigned long slack = 0;
rcu_read_lock();
retval = max_select_fd(n, fds);
rcu_read_unlock();
if (retval < 0)
return retval;
n = retval;
poll_initwait(&table);
wait = &table.pt;
if (end_time && !end_time->tv_sec && !end_time->tv_nsec) {
wait = NULL;
timed_out = 1;
}
if (end_time && !timed_out)
slack = estimate_accuracy(end_time);
retval = 0;
for (;;) {
unsigned long *rinp, *routp, *rexp, *inp, *outp, *exp;
set_current_state(TASK_INTERRUPTIBLE);
inp = fds->in; outp = fds->out; exp = fds->ex;
rinp = fds->res_in; routp = fds->res_out; rexp = fds->res_ex;
for (i = 0; i < n; ++rinp, ++routp, ++rexp) {
unsigned long in, out, ex, all_bits, bit = 1, mask, j;
unsigned long res_in = 0, res_out = 0, res_ex = 0;
const struct file_operations *f_op = NULL;
struct file *file = NULL;
in = *inp++; out = *outp++; ex = *exp++;
all_bits = in | out | ex;
if (all_bits == 0) {
i += __NFDBITS;
continue;
}
for (j = 0; j < __NFDBITS; ++j, ++i, bit <<= 1) {
int fput_needed;
if (i >= n)
break;
if (!(bit & all_bits))
continue;
file = fget_light(i, &fput_needed);
if (file) {
f_op = file->f_op;
mask = DEFAULT_POLLMASK;
if (f_op && f_op->poll)
mask = (*f_op->poll)(file, retval ? NULL : wait);
fput_light(file, fput_needed);
if ((mask & POLLIN_SET) && (in & bit)) {
res_in |= bit;
retval++;
}
if ((mask & POLLOUT_SET) && (out & bit)) {
res_out |= bit;
retval++;
}
if ((mask & POLLEX_SET) && (ex & bit)) {
res_ex |= bit;
retval++;
}
}
}
if (res_in)
*rinp = res_in;
if (res_out)
*routp = res_out;
if (res_ex)
*rexp = res_ex;
cond_resched();
}
wait = NULL;
if (retval || timed_out || signal_pending(current))
break;
if (table.error) {
retval = table.error;
break;
}
/*
* If this is the first loop and we have a timeout
* given, then we convert to ktime_t and set the to
* pointer to the expiry value.
*/
if (end_time && !to) {
expire = timespec_to_ktime(*end_time);
to = &expire;
}
if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
timed_out = 1;
}
__set_current_state(TASK_RUNNING);
poll_freewait(&table);
return retval;
}
上面的代码很多，其实真正关键的代码是这一句:
mask = (*f_op->poll)(file, retval ? NULL : wait);
这个是调用文件系统的 poll函数，不同的文件系统poll函数自然不同，由于我们这里关注的是tcp连接，而socketfs的注册在 net/Socket.c里。
register_filesystem(&sock_fs_type);
socket文件系统的函数也是在net/Socket.c里：
static const struct file_operations socket_file_ops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
.aio_read = sock_aio_read,
.aio_write = sock_aio_write,
.poll = sock_poll,
.unlocked_ioctl = sock_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = compat_sock_ioctl,
#endif
.mmap = sock_mmap,
.open = sock_no_open, /* special open code to disallow open via /proc */
.release = sock_close,
.fasync = sock_fasync,
.sendpage = sock_sendpage,
.splice_write = generic_splice_sendpage,
.splice_read = sock_splice_read,
};
从sock_poll跟随下去，
最后可以到 net/ipv4/tcp.c的
unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
这个是最终的查询函数，也就是说select 的核心功能是调用tcp文件系统的poll函数，不停的查询，如果没有想要的数据，主动执行一次调度（防止一直占用cpu），直到有一个连接有想要的消息为止。
从这里可以看出select的执行方式基本就是不停的调用poll,直到有需要的消息为止，如果select 处理的socket很多，这其实对整个机器的性能也是一个消耗。
二、Poll:
1. 背景
poll在1986年诞生于System V Release 3，它和select在本质上没有多大差别，但是poll没有最大FD数量的限制。
2. 限制
poll和select同样存在一个缺点就是通过遍历完成调度，IO效率随FD数目增加呈线性下降。
此外，包含大量FD的数组被整体复制于用户态和内核的地址空间之间，而不论这些FD是否就绪，它的开销随着FD数量的增加而线性增大。
三、Epoll:
1. 背景
直到Linux2.6才出现的由内核直接支持的实现方法，epoll被公认为Linux2.6下性能最好的多路I/O就绪通知方法。
2. 优点
2.1 Socket数量无限制(同Poll)
2.2 基于内核提供的反射模式激活socket
基于内核提供的反射模式,有活跃Socket时,内核访问该Socket的callback,不需要遍历轮询。
epoll采用基于事件的就绪通知方式。在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的FD进行扫描，而epoll事先通过epoll_ctl()来注册一个FD，一旦基于某个FD就绪时，内核会采用类似callback的回调机制，迅速激活这个FD，当进程调用epoll_wait()时便得到通知。
2.3 使用mmap加速内核与用户空间的消息传递
这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核与用户空间mmap同一块内存实现的。
epoll可以同时支持水平触发和边缘触发（Edge Triggered，只告诉进程哪些FD刚刚变为就绪状态，它只说一遍，如果我们没有采取行动，那么它将不会再次告知，这种方式称为边缘触发），理论上边缘触发的性能要更高一些，但是代码实现相当复杂。
epoll同样只告知那些就绪的FD，而且当我们调用epoll_wait()获得就绪FD时，返回的不是实际的FD，而是一个代表就绪FD数量的值，你只需要去epoll指定的一个数组中依次取得相应数量的FD即可，这里使用了内存映射（mmap）技术，这样便彻底省掉了这些文件描述符在系统调用时复制的开销。
2.4 内核微调
内核TCP/IP协议栈使用内存池管理sk_buff结构，在运行时期可以动态调整这个内存pool(skb_head_pool)的大小
--- 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。
listen函数的第2个参数(TCP完成3次握手的数据包队列长度)也可以根据平台内存大小动态调整。
在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上，可尝试最新的NAPI网卡驱动架构。
3.内核Epoll的实现
这段结合linux内核代码描述，我使用的是2.6.28。
epoll的实现代码在 fs/EventPoll.c下，
由于epoll涉及到几个系统调用，这里不逐个分析了，仅仅分析几个关键点，第一个关键点在
static int ep_insert(struct eventpoll *ep, struct epoll_event *event, struct file *tfile, int fd)
这是在我们调用sys_epoll_ctl 添加一个被管理socket的时候调用的函数，关键的几行如下：
epq.epi = epi;
init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);
/*
* Attach the item to the poll hooks and get current event bits.
* We can safely use the file* here because its usage count has
* been increased by the caller of this function. Note that after
* this operation completes, the poll callback can start hitting
* the new item.
*/
revents = tfile->f_op->poll(tfile, &epq.pt);
这里也是调用文件系统的poll函数，不过这次初始化了一个结构，这个结构会带有一个poll函数的callback函数：ep_ptable_queue_proc，
在调用poll函数的时候，会执行这个callback，这个callback的功能就是将当前进程添加到 socket的等待进程上。
static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,
poll_table *pt)
{
struct epitem *epi = ep_item_from_epqueue(pt);
struct eppoll_entry *pwq;
if (epi->nwait >= 0 && (pwq = kmem_cache_alloc(pwq_cache, GFP_KERNEL))) {
init_waitqueue_func_entry(&pwq->wait, ep_poll_callback);
pwq->whead = whead;
pwq->base = epi;
add_wait_queue(whead, &pwq->wait);
list_add_tail(&pwq->llink, &epi->pwqlist);
epi->nwait++;
} else {
/* We have to signal that an error occurred */
epi->nwait = -1;
}
}
注意到参数 whead 实际上是 sk->sleep，其实就是将当前进程添加到sk的等待队列里，当该socket收到数据或者其他事件触发时，会调用sock_def_readable 或者sock_def_write_space 通知函数来唤醒等待进程，这2个函数都是在socket创建的时候填充在sk结构里的。
从前面的分析来看，epoll确实是比select聪明的多、轻松的多，不用再苦哈哈的去轮询了。
===================================================================================
四、总结
总体来说:
大部分情况下,反射的效率都比遍历来的高,但是当所有Socket都活跃的时候,反射还会更高么?这时候所有的callback都被唤醒,会导致资源的竞争.既然都是要处理所有的Socket,那么遍历是最简单最有效的实现方式.
举例来说:
1. 对于IM服务器,服务器和服务器之间都是长链接,但数量不多,一般一台60/70个,比如采用ICE这种架构设计,但请求相当频繁和密集,这时候通过反射唤醒callback不一定比用select去遍历处理更好.
在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
2. 对于web portal服务器,都是浏览器客户端发起的http短链接请求,数量很大,好一点的网站动辄每分钟上千个请求过来,同时服务器端还有更多的闲置等待超时的Socket,这时候没必要把全部的Socket都遍历处理,因为那些等待超时的请求是大多数的,这样用Epoll会更好.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
