C10K问题的根源

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

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

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

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

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

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