如果不考虑内存大小的限制，在linux下面，fd （即file descriptor）的数量来自2个限制（阈值）。
其一：是操作系统的限制。
这个限制主要是在linux内核中，我们知道，用户程序的fopen操作最后都通过system call进入到linux kenrel。
linux kernel会对此进行检查，防止某个用户占用太多的系统资源。
现在的内核都可以通过sysctl命令在开机的时候来调整。他是不是还有一个代码级别的最大值（如定义了宏），我没有仔细研究关于此的代码，故不能确定。但据我所知，某些程序开上万个fd也是有在用的。
命令sysctl fs.file-max=655360可以调整内核的阈值，当然你得有root权限。想一劳永逸，参考/etc/sysctl.conf，用命令man sysctl.conf
命令sysctl -a可以显示所有的能够调整参数。
其二：是用户进程的限制。
举例，在bash环境下启动的程序将继承bash缺省的或用户定制的限制。
这个限制可以通过bash的内部命令ulimit来调整，当然不能高过操作系统的限制。
比如命令：ulimit -n 20规定了在当前bash环境下运行的程序只能同时打开20个fd，但是如果你做上面的测试程序，则只有17个。还有3个哪里去了？动脑筋想一下你应该能找到答案。
ulimit -n 命令只能往下调fd，不能往上调。如果你改的过小了，想反悔？好像只能关闭当前的bash再重新开启一个。
那么，bash又是从哪里继承的呢？参考/etc/security/limits.conf，用命令man limits.conf
ulimit -a可以显示包括fd在内的全部阈值：如最 大数据 段大小、最大代码段大小、最大栈大小、用户能创建的进程的最大数目、一个进程中线程的最大数目。
试试在s2服务器上运行此命令，结果应该是最大可同时打开1024个fd。
寻求更多的信息？老办法：输入命令man bash，然后查找ulimit。
其一：是操作系统的限制。
这个限制主要是在linux内核中，我们知道，用户程序的fopen操作最后都通过system call进入到linux kenrel。
linux kernel会对此进行检查，防止某个用户占用太多的系统资源。
现在的内核都可以通过sysctl命令在开机的时候来调整。他是不是还有一个代码级别的最大值（如定义了宏），我没有仔细研究关于此的代码，故不能确定。但据我所知，某些程序开上万个fd也是有在用的。
命令sysctl fs.file-max=655360可以调整内核的阈值，当然你得有root权限。想一劳永逸，参考/etc/sysctl.conf，用命令man sysctl.conf
命令sysctl -a可以显示所有的能够调整参数。
其二：是用户进程的限制。
举例，在bash环境下启动的程序将继承bash缺省的或用户定制的限制。
这个限制可以通过bash的内部命令ulimit来调整，当然不能高过操作系统的限制。
比如命令：ulimit -n 20规定了在当前bash环境下运行的程序只能同时打开20个fd，但是如果你做上面的测试程序，则只有17个。还有3个哪里去了？动脑筋想一下你应该能找到答案。
ulimit -n 命令只能往下调fd，不能往上调。如果你改的过小了，想反悔？好像只能关闭当前的bash再重新开启一个。
那么，bash又是从哪里继承的呢？参考/etc/security/limits.conf，用命令man limits.conf
ulimit -a可以显示包括fd在内的全部阈值：如最 大数据 段大小、最大代码段大小、最大栈大小、用户能创建的进程的最大数目、一个进程中线程的最大数目。
试试在s2服务器上运行此命令，结果应该是最大可同时打开1024个fd。
寻求更多的信息？老办法：输入命令man bash，然后查找ulimit。
