高并发情况下Linux系统及kernel参数优化:
默认参数情况下Linux对高并发支持并不好,主要受限于单进程最大打开文件数限制、内核TCP参数方面和IO事件分配机制等;
单进程最大打开文件数限制:
一般的发行版,限制单进程最大可以打开1024个文件;
修改root启动的单一进程的最大可以打开的文件数设置为65535:unlimit -n 65535
如果系统报错”Operationnotpermitted”之类的话,说明上述限制修改失败,实际上是因为在中指定的数值超过了Linux系统对该用户打开文件数的软限制和硬限制;
- 修改打开文件的软限制和硬限制:其中*号表示修改所有用户的限制,注意软限制值要小于或等于硬限制;
vim /etc/security/limits.conf* soft nofile 65535* hard nofile 65535
- 修改/etc/pam.d/login,告诉linux在用户完成系统登录后,应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制,而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值:
vim /etc/pam.d/login
sessionrequired /lib/security/pam_limits.so
- 查看linux系统级别的最大打开文件数限制:
cat /proc/sys/fs/file-max
表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)n个文件,通常这个系统级硬限制是linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制。修改方式修改/etc/sysctl.conf文件内fs.file-max=N
完成上述步骤后重启系统,一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值,这可能是因为在用户登录脚本/etc/profile中使用ulimit-n命令已经将用户可同时打开的文件数做了限制。由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时,新修改的值只能小于或等于上次ulimit-n设置的值,因此想用此命令增大这个限制值是不可能的。所以,如果有上述问题存在,就只能去打开/etc/profile脚本文件,在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量,如果找到,则删除这行命令,或者将其设置的值改为合适的值,然后保存文件,用户退出并重新登录系统即可。
内核TCP参数方面:
Linux系统下,TCP连接断开后,会以TIME_WAIT状态保留一定的时间,然后才会释放端口;当并发请求过多的时候,就会产生大量的TIME_WAIT状态的连接,无法及时断开的话,会占用大量的端口资源和服务器资源。这个时候我们可以优化TCP的内核参数,及时将TIME_WAIT状态的端口清理掉;
查看TCP连接的状态和对应的连接数量:netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
- 调整Linux的TCP内核参数,让系统更快的释放TIME_WAIT连接: ``` vim /etc/sysctl.conf net.ipv4.tcp_syncookied = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30
sysctl -p
<br />开启SYNCookies,当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,关闭;
net.ipv4.tcp_syncookied = 1
<br />开启重用,允许将TIME_WAIT sockets重新用于新的TCP连接,默认为0,关闭;
net.ipv4.tcp_tw_reuse = 1
<br />开启TCP连接中TIME_WAIT sockets的快速回收,默认为0,关闭;
net.ipv4.tcp_tw_recycle = 1
<br />修改系统默认的TIMEOUT时间;
net.ipv4.tcp_fin_timeout = 30
2.
如果连接数本身就很多,可以再优化以下TCP的可使用端口范围:
vim /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 1200 net.ipv4.ip_local_port_rang = 1024 65535 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_max_tw_buckets = 5000
<br />注:这几个参数,建议只在流量非常大的服务器上开始,会有显著的效果,一般的流量小的服务器上没有必要设置这几个参数;
net.ipv4.tcp_keepalive_time = 1200
<br />表示当keepalive起用的时候,TCP发送keepalive消息的频度,默认是2小时,改为20分钟;
net.ipv4.ip_local_port_rang = 1024 65535
<br />表示用于向外连接的端口范围,默认情况下很小 32768-61000,改为1024到65535;
net.ipv4.tcp_max_syn_backlog = 8192
<br />表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数;
net.ipv4.tcp_max_tw_buckets = 5000
<br />表示系统同时保持TIME_WAIT的最大数量,如果超过这个数字,TIME_WAIT将立刻被清除并打印警告信息,默认为180000,改为5000;
3.
内核其他TCP参数说明:
net.ipv4.tcp_max_syn_backlog = 65535
<br />记录的那些尚未收到客户端确认信息的连接请求的最大值,对于有128M内存的系统而言,缺省值是1024,小内存的系统是128;
net.core.netdev_max_backlog = 32768
<br />每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目;
net.core.somaxconn = 32768
<br />表示socket监听(listen)的backlog上限,backlog就是socket的监听队列,当一个request尚未被处理或建立时,它会进入backlog;而socket server可以一次性处理backlog中的所有请求,处理后的请求不再位于监听队列中,当server处理request较慢,以至于监听队列被填满后,新来的请求会被拒绝;
<br />例如web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128,而nginx定义的NGX_LISTEN_BACKLOG默认为511,所以有必要调整这个值;
net.core.wmem_default = 8388608 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_timestamps = 0
<br />时间戳可以避免序列号的卷绕,一个1Gbps的链路肯定会遇到以前用过的序列号,时间戳能够让内核接受这种“异常”的数据包,这里需要将其关掉;
net.ipv4.tcp_synack_retries = 2
<br />为了打开对端的连接,内核需要发送一个SYN并附带一个回应前面一个SYN的AC看,也就是所谓的三次握手中的第二次握手,这个设置决定了内核放弃连接之前发送SYN+ACK包的数量;
net.ipv4.tcp_syn_retries = 2
<br />在内核放弃建立连接之前发送SYN包的数量;
net.ipv4.tcp_tw_reuse = 1
<br />开启重用,允许将TIME_WAIT sockets重新用于新的TCP连接;
net.ipv4.tcp_wmem = 8192 436600 873200
<br />TCP写buffer,可参考的优化值8192 436600 873200
net.ipv4.tcp_rmem = 32768 436600 873200
<br />TCP读buffer,可参考的优化值:32768 436600 873200
net.ipv4.tcp_mem = 94500000 91500000 92700000
<br />同样有3个值,意思是:
net.ipv4.tcp_mem[0]: 低于此值,TCP没有内存压力; net.ipv4.tcp_mem[1]: 在此值下,进入内存压力阶段; net.ipv4.tcp_mem[2]: 高于此值,TCP拒绝分配socket;
<br />如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接,甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒,你可以按这个设置,但要记住的是,即使你的机器是一个轻载的WEB服务器,也有因为大量的死套接字而内存溢出的风险,FIN-WAIT-2的危险性比FIN-WAIT-1要小,因为它最多只能吃掉1.5K内存,但是它们的生存期长些;
net.ipv4.tcp_fin_timeout = 30
<br />本机提供的拥塞算法控制模块:
sysctlnet.ipv4.tcp_available_congestion_control
<br />TCP拥塞控制算法的优缺点、适用环境、性能分析,比如高延时时可以使用hybla,中等延时可以试用htcp算法等;
net.ipv4.tcp_congestion_control = hybla
<br />对于内核高于3.7.1的,我可以开启tcp_fastopen:
net.ipv4.tcp_fastopen = 3 ```
IO事件分配机制
在Linux启用高并发TCP连接,必须确认应用程序是否使用了合适的网络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保证。
