C10K问题的根源

C10K问题的根源_第1张图片

C10K是一个现象,其根源在于程序员“想当然”

  • 同时工作的进程数
    历史上UNIX的进程ID是16位整数,也就是进程最多不超过32767。现代的Linux系统进程ID虽然是32位,但是系统仍然限制了大小。想要一个连接一个进程,必然会触发其上限。

  • 内存的容量足够处理所创建的进程和线程
    系统进程和线程是有一定内存消耗的(1~2M),1w个需要10G。这样一来光系统就把内存吃光了。

  • 同时打开文件描述符
    Linux默认情况下,一个进程所能打开文件最大数量是1024个。考虑用单进程处理所以连接必须注意到这点。

  • 对多个文件描述符进行监视,用select系统调用
    select虽然有上限,用多个进程是不是可以规避这个问题?这也是想当然。select本身就是一个轮询的实现,不管怎么用都无法改变。

操作系统后来也给出了解决方案,但无论如何,处理的上限任然是存在的:也许是C100K,或者是C1000K。解决C10K并不重要,重要的是要知道,在当前系统架构下,系统的上限是多少。决定这个上限的,是系统里最薄弱的部分

你可能感兴趣的:(C10K问题的根源)