(1) vi /etc/security/limits.conf session required /lib/security/pam_limits.so (1) vi /etc/rc.d/rc.local /sbin/modprobe ip_conntrack # 加载
ip_contrack 模块
# /sbin/sysctl –p # 使
/etc/sysctl.conf 的配置生效,根据实际情况来决定是否添加此命令
[root@AS4U8 ~]# sysctl -a | grep "net.ipv4.ip" net.ipv4.ip_conntrack_max = 16384 这表明将系统对最大跟踪的
TCP 连接数限制默认为
16384 。请注意,此限制值要尽量小,以节省对内核内存的占用
net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.ip_conntrack_max = 10240 在
Linux 平台上,无论编写客户端程序还是服务端程序,在进行高并发
TCP 连接处理时,最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制
( 这是因为系统为每个
TCP 连接都要创建一个
socket 句柄,每个
socket 句柄同时也是一个文件句柄
) 。可使用
ulimit 命令查看系统允许当前用户进程打开的文件数限制:
这表示当前用户的每个进程最多允许同时打开
1024 个文件,这
1024 个文件中还得除去每个进程必然打开的标准输入,标准输出,标准错误,服务器监听
socket ,进程间通讯的
unix 域
socket 等文件,那么剩下的可用于客户端
socket 连接的文件数就只有大概
1024-10=1014 个左右。也就是说缺省情况下,基于
Linux 的通讯程序最多允许同时
1014 个
TCP 并发连接。
对于想支持更高数量的
TCP 并发连接的通讯处理程序,就必须修改
Linux 对当前用户的进程同时打开的文件数量的软限制
(soft limit) 和硬限制
(hardlimit) 。其中软限制是指
Linux 在当前系统能够承受的范围内进一步限制用户同时打开的文件数;硬限制则是根据系统硬件资源状况
( 主要是系统内存
) 计算出来的系统最多可同时打开的文件数量。通常软限制小于或等于硬限制。
修改上述限制的最简单的办法就是使用
ulimit 命令:
[speng@as4 ~]$ ulimit -n <file_num> 上述命令中,在
<file_num> 中指定要设置的单一进程允许打开的最大文件数。如果系统回显类似于“
Operation notpermitted ”之类的话,说明上述限制修改失败,实际上是因为在
<file_num> 中指定的数值超过了
Linux 系统对该用户打开文件数的软限制或硬限制。因此,就需要修改
Linux 系统对用户的关于打开文件数的软限制和硬限制。
第一步,修改
/etc/security/limits.conf 文件,在文件中添加如下行:
其中
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 系统级的最大打开文件数限制,使用如下命令:
[speng@as4 ~]$ cat /proc/sys/fs/file-max 这表明这台
Linux 系统最多允许同时打开
( 即包含所有用户打开文件数总和
)12158 个文件,是
Linux 系统级硬限制,所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是
Linux 系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制,如果没有特殊需要,不应该修改此限制,除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改
/etc/rc.local 脚本,在脚本中添加如下行:
echo 22158 > /proc/sys/fs/file-max 这是让
Linux 在启动完成后强行将系统级打开文件数硬限制设置为
22158 。修改完后保存此文件。
完成上述步骤后重启系统,一般情况下就可以将
Linux 系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用
ulimit-n 命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值,这可能是因为在用户登录脚本
/etc/profile 中使用
ulimit-n 命令已经将用户可同时打开的文件数做了限制。由于通过
ulimit-n 修改系统对用户可同时打开文件的最大数限制时,新修改的值只能小于或等于上次
ulimit-n 设置的值,因此想用此命令增大这个限制值是不可能的。所以,如果有上述问题存在,就只能去打开
/etc/profile 脚本文件,在文件中查找是否使用了
ulimit-n 限制了用户可同时打开的最大文件数量,如果找到,则删除这行命令,或者将其设置的值改为合适的值,然后保存文件,用户退出并重新登录系统即可。
通过上述步骤,就为支持高并发
TCP 连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。
在
Linux 上编写支持高并发
TCP 连接的客户端通讯处理程序时,有时会发现尽管已经解除了系统对用户同时打开文件数的限制,但仍会出现并发
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 assignrequested address ”。有关这些控制逻辑可以查看
Linux 内核源代码,以
linux2.6 内核为例,可以查看
tcp_ipv4.c 文件中如下函数:
static int tcp_v4_hash_connect(struct sock *sk) 请注意上述函数中对变量
sysctl_local_port_range 的访问控制。变量
sysctl_local_port_range 的初始化则是在
tcp.c 文件中的如下函数中设置:
void __init tcp_init(void) 内核编译时默认设置的本地端口号范围可能太小,因此需要修改此本地端口范围限制。
第一步,修改
/etc/sysctl.conf 文件,在文件中添加如下行:
net.ipv4.ip_local_port_range = 1024 65000 这表明将系统对本地端口范围限制设置为
1024~65000 之间。请注意,本地端口范围的最小值必须大于或等于
1024 ;而端口范围的最大值则应小于或等于
65535 。修改完后保存此文件。
如果系统没有错误提示,就表明新的本地端口范围设置成功。如果按上述端口范围进行设置,则理论上单独一个进程最多可以同时建立
60000 多个
TCP 客户端连接。
第二种无法建立
TCP 连接的原因可能是因为
Linux 网络内核的
IP_TABLE 防火墙对最大跟踪的
TCP 连接数有限制。此时程序会表现为在
connect() 调用中阻塞,如同死机,如果用
tcpdump 工具监视网络,也会发现根本没有
TCP 连接时客户端发
SYN 包的网络流量。由于
IP_TABLE 防火墙在内核中会对每个
TCP 连接的状态进行跟踪,跟踪信息将会放在位于内核内存中的
conntrackdatabase 中,这个数据库的大小有限,当系统中存在过多的
TCP 连接时,数据库容量不足,
IP_TABLE 无法为新的
TCP 连接建立跟踪信息,于是表现为在
connect() 调用中阻塞。此时就必须修改内核对最大跟踪的
TCP 连接数的限制,方法同修改内核对本地端口号范围的限制是类似的:
第一步,修改
/etc/sysctl.conf 文件,在文件中添加如下行:
net.ipv4.ip_conntrack_max = 10240 这表明将系统对最大跟踪的
TCP 连接数限制设置为
10240 。请注意,此限制值要尽量小,以节省对内核内存的占用。
如果系统没有错误提示,就表明系统对新的最大跟踪的
TCP 连接数限制修改成功。如果按上述参数进行设置,则理论上单独一个进程最多可以同时建立
10000 多个
TCP 客户端连接。
在
Linux 上编写高并发
TCP 连接应用程序时,必须使用合适的网络
I/O 技术和
I/O 事件分派机制。
可用的
I/O 技术有同步
I/O ,非阻塞式同步
I/O( 也称反应式
I/O) ,以及异步
I/O 。在高
TCP 并发的情形下,如果使用同步
I/O ,这会严重阻塞程序的运转,除非为每个
TCP 连接的
I/O 创建一个线程。但是,过多的线程又会因系统对线程的调度造成巨大开销。因此,在高
TCP 并发的情形下使用同步
I/O 是不可取的,这时可以考虑使用非阻塞式同步
I/O 或异步
I/O 。非阻塞式同步
I/O 的技术包括使用
select() ,
poll() ,
epoll 等机制。异步
I/O 的技术就是使用
AIO 。
从
I/O 事件分派机制来看,使用
select() 是不合适的,因为它所支持的并发连接数有限
( 通常在
1024 个以内
) 。如果考虑性能,
poll() 也是不合适的,尽管它可以支持的较高的
TCP 并发数,但是由于其采用“轮询”机制,当并发数较高时,其运行效率相当低,并可能存在
I/O 事件分派不均,导致部分
TCP 连接上的
I/O 出现“饥饿”现象。而如果使用
epoll 或
AIO ,则没有上述问题
( 早期
Linux 内核的
AIO 技术实现是通过在内核中为每个
I/O 请求创建一个线程来实现的,这种实现机制在高并发
TCP 连接的情形下使用其实也有严重的性能问题。但在最新的
Linux 内核中,
AIO 的实现已经得到改进
) 。
综上所述,在开发支持高并发
TCP 连接的
Linux 应用程序时,应尽量使用
epoll 或
AIO 技术来实现并发的
TCP 连接上的
I/O 控制,这将为提升程序对高并发
TCP 连接的支持提供有效的
I/O 保证。