Linux高并发踩过的坑及性能优化介绍

前言

linux操作系统是现在服务器的首选操作系统，在linux的默认系统参数下，linux针对高并发的支持性并不是很好。小编从事linux下应用程序开发多年，关于linux系统下的高并发，小编自己踩过的坑，及如何解决踩过的坑下面列上几条，供大家参考，避免再次掉坑。

linux应用运行过程中出现too many open files 问题分析和解决

出现这句提示的原因是程序打开的文件socket连接数量超过系统设定值。

查看每个用户最大允许打开的文件数量

ulimit -a

其中 open files (-n) 1024 表示每个用户最大允许打开的文件数量是1024

当前系统文件句柄的最大数目，只用于查看，不能设置修改

cat /proc/sys/fs/file-max

查看某个进程的打开文件限制数

cat /proc/10446(pid)/limits

设置open files 数值方法

ulimit -n 65535 

这种设置方法在重启后会还原为默认值。

永久设置方法：

vim /etc/security/limits.conf

在最后加入

* soft nofile 65535

* hard nofile 65535

生效需要重启系统

这样修改之后，问题得到有效解决。

linux高并发下 time_wait 过多的问题分析及解决

现象是高并发场景下，服务器运行应用卡顿。

排查方法：查看服务器配置：

netstat -ant|awk '/^tcp/ {++s[$nf]} end {for(a in s) print (a,s[a])}'

发现处于 time_wait 的数量太多，有几万条，应该是大量socket处于time_wait状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
tcp连接状态描述：

closed：无连接是活动的或正在进行
listen：服务器在等待进入呼叫
syn_recv：一个连接请求已经到达，等待确认
syn_sent：应用已经开始，打开一个连接
established：正常数据传输状态
fin_wait1：应用说它已经完成
fin_wait2：另一边已同意释放
itmed_wait：等待所有分组死掉
closing：两边同时尝试关闭
time_wait：另一边已初始化一个释放
last_ack：等待所有分组死掉

time_wait过多危害

网络情况不好时，如果主动方无time_wait等待，关闭前个连接后，主动方与被动方又建立起新的tcp连接，这时被动方重传或延时过来的fin包过来后会直接影响新的tcp连接；
同样网络情况不好并且无time_wait等待，关闭连接后无新连接，当接收到被动方重传或延迟的fin包后，会给被动方回一个rst包，可能会影响被动方其它的服务连接。

针对如何解决time_wait 过多这一问题，解答如下：

编辑内核文件/etc/sysctl.conf，加入以下内容：

net.ipv4.tcp_syncookies = 1 #表示开启syn cookies。当出现syn等待队列溢出时，启用cookies来处理，可防范少量syn攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 #表示开启重用。允许将time-wait sockets重新用于新的tcp连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 #表示开启tcp连接中time-wait sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout =30#修改系默认的 timeout 时间

然后执行 /sbin/sysctl -p 让参数生效.

简单来说，就是打开系统的timewait重用和快速回收。

linux更多性能优化

如果您的系统的连接数本身就很多，如果以上配置调优后性能还不理想，可以再优化一下tcp的可使用端口范围，进一步提升服务器的并发能力。依然是/etc/sysctl.conf文件中，加入下面这些配置：

vi /etc/sysctl.conf
#表示当keepalive起用的时候，tcp发送keepalive消息的频度。缺省是2小时，改为20分钟。
net.ipv4.tcp_keepalive_time = 1200 
#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
net.ipv4.ip_local_port_range = 1024 65000 
#表示syn队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_syn_backlog = 8192 
#表示系统同时保持time_wait套接字的最大数量，如果超过这个数字，time_wait套接字将立刻被清除并打印警告信息。默认为180000，改为5000。对于apache、nginx等服务器，上几行的参数可以很好地减少time_wait套接字数量，但是对于 squid，效果却不大。此项参数可以控制time_wait套接字的最大数量，避免squid服务器被大量的time_wait套接字拖死。
net.ipv4.tcp_max_tw_buckets = 5000 

linux内核更多参数优化说明

vim /etc/sysctl.conf

1、net.ipv4.tcp_max_syn_backlog = 65536

记录的那些尚未收到客户端确认信息的连接请求的最大值。对于超过128m内存的系统而言，缺省值是1024，低于128m小内存的系统则是128。

syn flood攻击利用tcp协议散布握手的缺陷，伪造虚假源ip地址发送大量tcp-syn半打开连接到目标系统，最终导致目标系统socket队列资源耗尽而无法接受新的连接。为了应付这种攻击，现代unix系统中普遍采用多连接队列处理的方式来缓冲(而不是解决)这种攻击，是用一个基本队列处理正常的完全连接应用(connect()和accept() )，是用另一个队列单独存放半打开连接。

这种双队列处理方式和其他一些系统内核措施(例如syn-cookies/caches)联合应用时，能够比较有效的缓解小规模的syn flood攻击(事实证明<1000p/s)加大syn队列长度可以容纳更多等待连接的网络连接数，一般遭受syn flood攻击的网站，都存在大量syn_recv状态，所以调大tcp_max_syn_backlog值能增加抵抗syn攻击的能力。

2、net.core.netdev_max_backlog = 32768

每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。

3、net.core.somaxconn = 32768

调整系统同时发起并发tcp连接数，可能需要提高连接储备值，以应对大量突发入局连接请求的情况。如果同时接收到大量连接请求，使用较大的值会提高受支持的暂挂连接的数量，从而可减少连接失败的数量。大的侦听队列对防止ddos攻击也会有所帮助。挂起请求的最大数量默认是128。

查看实时内核实时丢包命令：

netstat-su

位置：/proc/sys/

4、net.core.wmem_default = 8388608

该参数指定了发送套接字缓冲区大小的缺省值(以字节为单位)

5、net.core.rmem_default = 8388608

该参数指定了接收套接字缓冲区大小的缺省值(以字节为单位)

6、net.core.rmem_max = 16777216

该参数指定了接收套接字缓冲区大小的最大值(以字节为单位)

7、net.core.wmem_max = 16777216

该参数指定了发送套接字缓冲区大小的最大值(以字节为单位)

8、net.ipv4.tcp_timestamps = 0

timestamps可以防范那些伪造的sequence号码。一条1g的宽带线路或许会重遇到带out-of-line数值的旧sequence号码(假如它是由于上次产生的)。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉,以提高性能。

9、net.ipv4.tcp_synack_retries = 2

对于远端的连接请求syn，内核会发送syn＋ack数据报，以确认收到上一个syn连接请求包。这是所谓的三次握手(threeway handshake)机制的第二个步骤。这里决定内核在放弃连接之前所送出的syn+ack数目。不应该大于255，默认值是5，对应于180秒左右时间。(可以根据tcp_syn_retries来决定这个值)

10、net.ipv4.tcp_syn_retries = 2

对于一个新建连接，内核要发送多少个syn连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右时间。(对于大负载而物理通信良好的网络而言,这个值偏高,可修改为2.这个值仅仅是针对对外的连接,对进来的连接,是由tcp_retries1 决定的)

#net.ipv4.tcp_tw_len = 1

11、net.ipv4.tcp_tw_reuse = 1

表示开启重用，允许将time-wait sockets重新用于新的tcp连接，默认为0，表示关闭。这个对快速重启动某些服务,而启动后提示端口已经被使用的情形非常有帮助。

12、net.ipv4.tcp_mem = 94500000 915000000 927000000

tcp_mem有3个integer变量：low, pressure, high

low：当tcp使用了低于该值的内存页面数时，tcp没有内存压力，tcp不会考虑释放内存。(理想情况下，这个值应与指定给tcp_wmem的第2个值相匹配。这第2个值表明，最大页面大小乘以最大并发请求数除以页大小 (131072*300/4096)

pressure：当tcp使用了超过该值的内存页面数量时，tcp试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出pressure状态。(理想情况下这个值应该是tcp可以使用的总缓冲区大小的最大值(204800*300/4096)

high：允许所有tcp sockets用于排队缓冲数据报的页面量。如果超过这个值，tcp连接将被拒绝，这就是为什么不要令其过于保守(512000*300/4096)的原因了。在这种情况下，提供的价值很大，它能处理很多连接，是所预期的2.5倍；或者使现有连接能够传输2.5倍的数据。

一般情况下这些值是在系统启动时根据系统内存数量计算得到的。

13、net.ipv4.tcp_max_orphans = 3276800

系统所能处理不属于任何进程的tcp sockets最大数量。假如超过这个数量﹐那么不属于任何进程的连接会被立即reset，并同时显示警告信息。之所以要设定这个限制﹐纯粹为了抵御那些简单的dos攻击﹐千万不要依赖这个或是人为的降低这个限制

14、net.ipv4.tcp_fin_timeout = 30

如果套接字由本端要求关闭，这个参数决定了它保持在fin-wait-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的web服务器，也有因为大量的死套接字而内存溢出的风险，fin-wait-2的危险性比fin-wait-1要小，因为它最多只能吃掉1.5k内存，但是它们的生存期长些。

15、net.ipv4.ip_conntrack_max = 10000

设置系统对最大跟踪的tcp连接数的限制(centos 5.6无此参数)

同时还涉及到一个tcp 拥塞算法的问题，你可以用下面的命令查看本机提供的拥塞算法控制模块：

sysctlnet.ipv4.tcp_available_congestion_control

对于几种算法的分析，详情可以参考下：tcp拥塞控制算法的优缺点、适用环境、性能分析，比如高延时可以试用hybla，中等延时可以试用htcp算法等。

如果想设置tcp 拥塞算法为hybla

#设置tcp 拥塞算法
net.ipv4.tcp_congestion_control=hybla

对于内核版高于于3.7.1的，我们可以开启tcp_fastopen：

#开启tcp_fastopen
net.ipv4.tcp_fastopen= 3

iptables相关

如非必须，关掉或卸载iptables防火墙，并阻止kernel加载iptables模块。这些模块会影响并发性能。

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保证。

经过以上描述的优化配置之后，服务器的tcp并发处理能力会显著提高。上文所述配置仅供参考，用于生产环境请根据自己开发系统所部署的实际情况调整观察再调整。

到此这篇关于linux高并发踩过的坑及性能优化介绍的文章就介绍到这了,更多相关linux高并发及性能优化内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！