Linux打开文件限制
1、修改用户进程可打开文件数限制
在linux平台上，无论是客户端程序还是服务器端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文件句柄)。
可使用ulimit命令查看系统允许当前用户进程打开的文件数限制：
~]# ulimit -n
1024
这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出，标准错误，服务器监听socket，进程间通信的unix与socket等文件，那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右，也就是说缺省情况下，基于linux的通信程序最多允许同时1014个tcp并发连接。
修改上述限制的最简单的办法就是使用ulimit命令：
~]# ulimit -n
上述命令中，在
第一步，修改/etc/security/limits.conf文件，在文件中添加如下：
speng soft nofile 10240
speng hard nofile 10240
其中speng指定了要修改哪个用户的打开文件数限制，可用'*'号表示修改所有用户的限制，soft或hard指定要修改软限制还是硬限制，10240则指定了想要修改的新的限制值，即最大打开文件数(软限制应该要小于硬限制，软限制即表示阀值，超过会产生告警)，修改完后保存文件。
第二步，修改/etc/pam.d/login文件，在文件中添加如下行:
session required /lib/security/pam_limits.so
这是告诉linux在用户完成系统登陆后，应该调用pam__limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制），而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值，修改后保存到此文件。
第三步，查看linux系统级的最大打开文件数限制，使用如下命令：
~]# cat /proc/sys/fs/file-max
184289
~]# cat /proc/sys/fs/file-nr
1024 0 184289
已分配文件句柄的数目 分配了但没有使用的句柄数 文件句柄最大数目
这表明这台linux系统最多允许同时打开（即包含所有用户打开文件数总和）184289个文件，是linux系统硬件级限制，所有用户级的打开文件数限制都不应超过这个数值，通常这个系统级硬限制是linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值，修改此硬限制的方法是修改/etc/rc.local脚本，在脚本中添加如下行：
echo 284289 > /proc/sys/fs/file-max
这是让linux在启动完成后强行将系统级打开文件数硬限制设置为284289，修改完后保存此文件。
完成上述步骤重启系统，一般情况下就可以将linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值，如果重启后用ulimit -n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登陆脚本/etc/profile中使用ulimit -n命令将用户可同时打开的文件数做了限制，由于通过ulimit -n修改系统对用户可同时打开文件的最大限制时，新修改的值只能小于或等于上次ulimit -n设置的值，因此想用此命令增大这个限制值，是不可能的，所以，如果上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找使用使用ulimit -n限制了用户可同时打开的最大文件数量，删除此命令，或将其修改成合适的值，保存文件，用户退出并重新登陆系统即可。
通过上述步骤，就为了支持高并发TCP连接处理的通信处理程序解除关于打开文件数量方面的系统限制。
2、修改网络内核对TCP连接的有关限制
在linux上，有时会发现尽管已经解除雷人系统对用户同时打开文件数的限制，但仍会出现并发TCP连接数增加到一定数量时，在也无法成功建立新的TCP连接的现象，出现这种情况的原因有很多。
第一种原因可能是因为linux网络内核对本地端口号范围有限制，此时进一步分析为什么无法建立TCP连接，会发现问题出在connect()调用返回失败，查看系统错误提示"can't assign requestedaddress"，同时如果在此时用tcpdump工具监视网络，会发现根本没有tcp连接时客户端发syn包的网络流量，这些情况说明问题在于本地linux系统内核中有限制，其实问题的根本原因在于linux内核的TCP/IP协议实现模块对系统中所有客户端TCP连接对应的本地端口号的范围进行了限制，（内核限制本地端口号范围1024~32768之间),当系统中某一时刻存在太多的tcp客户端连接时，由于每个tcp客户端连接都要占用一个唯一的本地端口，(此端口号在系统的本地端口范围限制中)，如果现有的tcp客户端连接已将所有的本地端口占满，则此时就无法为新的TCP客户端连接分配一个本地端口号了，因此系统会在这种情况下在connect()调用中返回失败，并将错误信息提示"can't assign requestedaddress"，有关这些控制逻辑可以查看linux内核源代码，以2.6版本为例，可以查看tcp_ipv4.c文件中如下函数：
static int tcp_v4_hash_connect(struct sock *sk)
=====
内核在编译时默认设置的本地端口号范围可能太小，因此需要修改此本地端口号范围限制
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_local_port_range = 1024 65000
这表明将系统对本地端口范围限制为1024~65000之间，请注意，本地端口号范围的最小值必须大于等于1024,而端口号范围的最大值则应小于等于65535，修改完成后保存此文件。
第二步，执行sysctl命令：
~]# sysctl -p
如果系统没有错误提示，就表面新的本地端口范围设置成功，则理论上单独一个进程最多可以同事建立60000多个TCP客户端连接。
第二种无法建立TCP连接的原因可能是因为linux网络内额的iptable(netfilter)防火墙对最大跟踪的TCP连接数有限制，此时程序表现为connect()调用中阻塞，如同死机，由于iptable防火墙在内核中会对每个TCP连接的状态进行跟踪，跟踪信息将会放在位于内核内存中的conntrackdatabase中，这个数据库大小有限制，当系统中存在过多的TCP连接时，数据库容量不足，iptable无法为新的TCP连接建立跟踪信息，于是表现为connect()调用中阻塞，此时就必须修改内核对最大跟踪TCP连接数的限制，方法同修改内核对本地端口号范围的限制是类似的，
第一步，修改/etc/sysctl.conf文件，在文件中添加如下行：
net.ipv4.ip_conntrack_max = 10240
这表明将系统对最大跟踪的TCP连接数限制设置为10240，请注意此值要尽量小，节省对内核内存的占用
第二步，执行sysctl命令：
~]# sysctl -p
sysctl -p 报错net.ipv4.ip_conntrack_max" is an unknown key 则：modprobe ip_conntrack