最大文件描述符限制对高性能Web架构的影响

不同于Windows平台的高效的线程机制, Linux/Unix系统早期通过多进程来解决Web大规模并发访问量的问题. 而随着Linux内核的改进, 单纯增加进程数量的方式也慢慢被弃用, 转而使用单进程异步IO接口, 比如epoll(Linux), kqueue(BSD).

单进程异步IO接口可以简单理解为, 进程把大量的socket连接交给内核管理, 一旦连接中有数据需要处理, 则激活进程进行处理. 这样, 一个进程同时打开的socket(也即文件描述符)就有成千上万个.

Linux系统默认的单个进程所能打开的最大文件描述符一般是1024(可通过ulimit -n命令查询), 这就导致了文件描述符被用完的情况出现. 所以, 要开发能处理高并发请求的Web系统, 必须修改操作系统的最大文件描述符.

即使使用的是Apache这样的多进程Web服务器, 也有可能被最大文件描述符限制给绊倒, 因为后端可能使用的是fastcgi, memcached这些应用. 比如memcached, 一般使用的就是单进程异步IO接口, fastcgi的PHP脚本与其连接时, 将保持TCP长连接, 也是会消耗大量的文件描述符.

所以, 运行在Linux之上的高性能Web系统, 一定要扩大进程的最大文件描述符限制, 这是有很惨痛经验教训的.

　如果大量的客户端访问ttserver，请确保文件描述符够用。许多服务器的默认文件描述符为1024，可以在启动ttserver前使用ulimit命令提高这项值。例如：

ulimit -SHn 51200