点击展开

行业资讯

技术分享 Linux高并发踩过的坑及性能优化
2022-07-21 06:39:20 | 来源:火狐体育官方登录开户 作者:火狐体育直播吧

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

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

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

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

  记录的那些尚未收到客户端确认信息的连接请求的最大值。对于超过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攻击的能力。

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

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

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

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

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

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

  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倍的数据。

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

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

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

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

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

  在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并发处理能力会显著提高。上文所述配置仅供参考,用于生产环境请根据自己开发系统所部署的实际情况调整观察再调整。

火狐体育直播吧
火狐体育官方登录开户

火狐体育直播吧

联系电话:176 0301 6881

邮箱:sales@finscm.com

火狐体育官方登录开户