HA架构关于应对高并发

Posted 2020-09-14

前言：新项目上线，考验高并发，预选使用LR录制脚本跑脚本，考虑到搭建，使用简便的jmeter工具，       来跑500、1000、1500、2000的并发并打出报告，中间经历过tomcat与jmeter优化。

      高并发下考虑的层面  系统  +  nginx(理论3W左右)  +  tomcat--- 标签（tcp）

实际操作：

      1、

    

   方案：2000个线程，采取并大（可以选择单个线程间隔），错误日志实时打印

         当并发量达到1740时候，出现报错，报错日志在附件jmeter.txt.

              此时服务器，cpu占用量为2.5%  高于平时1.5%-2%，

                     Memcache大概多消耗1.4G-2G之间。

                     Tcp连接数监控 从150左右飙升至2400左右，无影响

              此时：服务器情况良 好

          另：tcp连接超过3000时候（昨天测试接口4700并发）。出现cpu报警，开始优化架构

开始排查：

发现报错，不是服务端报错，是不是jmeter工具内存飙高，发现自己pc内存吃紧，关闭其他程序，并且调整jmeter内存，再跑。

2017/04/25 13:59:59 INFO  - jmeter.threads.JMeterThread: Thread finished: 线程组 1-484 

2017/04/25 13:59:59 ERROR - jmeter.threads.JMeterThread: Test failed! java.lang.OutOfMemoryError: unable to create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Unknown Source)

at sun.net.www.http.KeepAliveCache$1.run(Unknown Source)

at sun.net.www.http.KeepAliveCache$1.run(Unknown Source)

           

            调整之后再次跑并发测试，

     

      报错结果为后端服务端接收http请求后返回异常

   

           系统层面：

            tcp连接数超过5000，没问题

             

       连接中统计连接超时

         

        死套接字超过1000，第一次是2200左右，第二次是1200，说明死套接字回收正常，速度还是可         以的

    再看一下。我的系统曾经做过的调优

       

应用服务器优化：

          基本的+

【处理器子系统调优】：开启超线程，处理器，重要性不言而喻，cpu性能经常是瓶颈，Hyper-Threading（超线程功能，基于SMP 内核），

Hyper-Threading 在操作系统里将一颗处理器虚拟化为两颗使用，使得处理器，同一时刻，可以执行两个线程或进程

TIME_WAIT相关sysctl参数及超时时间

[[email protected] ~]# sysctl -a | grep tw

net.ipv4.tcp_max_tw_buckets  //处于TIME_WAIT状态的socket数目的最大值

net.ipv4.tcp_tw_recycle = 1 //打开TIME_WAIT快速回收机制

net.ipv4.tcp_tw_reuse //TIME_WAIT状态socket复用

Sysctl –w net.ipv4.tcp_tw_len = 2   设置TIME_WAIT在2秒后超时

      果断调整tomcat内存情况，（此时系统资源合理）

         

       还是后端压力过大，死套接字还是占据tcp资源，返回

        Server returned HTTP response code: 502 for URL:                http://app.yunce56.cn/v10/message/test/list

       

     来看一下大婶们关于这波测试给出的建议

       

假死有两种情况，1种是time_wait过多，一种是close_wait过多，前者自行优化，后者开发程序问题

我帮你百度了一下，得出一条结论：这个错误是由于服务器压力过大，不能及时处理client的请求导致服务器响应超时而抛出的错误

       

基本上可以得出结论：

      即使做过死套接字回收机制+tomcat优化，应用服务器也无法支持瞬间大并发3000，单台服务器理论65535.停留在涉及理论，（根据业务，有长连接或者是持续连接，做tcp连接回收机制，重点谨慎考虑）

之后采取措施：使用haproxy/lvs + nginx(s)+tomcat(s)。来因对并发，单台服务器并发3000即有3%左               右连接数无法得到后端及时响应。

返回测试结果。调整架构方案。

架构方案（方案 + 回退机制）

方案

注重要的，关于80端口是谁提供的服务，根据架构决定，后来是haproxy+nginx

服务器采购

nginx书写

haproxy书写

上一篇文章书写，关于tomcat优化，借鉴之前的经验

http://chennailong.blog.51cto.com/10063928/1883671

方案提出，等待夜晚来临，运维，are you ready ? 2017年4月26日  22:00-凌晨

本文出自 “青春” 博客，请务必保留此出处http://chennailong.blog.51cto.com/10063928/1919737