来源：https://urlify.cn/jyYny2对于在线系统调整，它本身就是一项技术活动。它不仅需要强大的技术战斗能力，而且还需要强大的问题定位，问题识别和故障排除功能，以及强大的调整功能。
本文将从实际战斗的角度，问题识别，问题位置，问题分析，解决方案建议，解决方案实施，监视和调整后的解决方案以及调整后的观察的角度与您分享。以高并发度调整整个闭环过程。
1.项目概述该项目是一个基于SSM体系结构的购物中心类型的单一体系结构项目。其中，有一个秒杀大片模块。
以下是当前在线环境的简要架构部署图。总体描述：（1）该项目是SSM体系结构（2）服务器类别：1个负载平衡服务器（F5），3个应用程序服务器，1个计时器服务器，1个redis服务器，1个映像服务器服务器和1个基于Mysql主从服务器的服务器On Pass体系结构（Microsoft Cloud）（3）调用逻辑2.什么是整体体系结构项目从体系结构开发的角度来看，软件项目已经经历了以下开发阶段：1.整体体系结构：可以理解为传统的，不可分离的体系结构前端和后端之间的体系结构2.垂直体系结构：可以理解为前端和后端分离的体系结构。
3. SOA体系结构：可以将其理解为基于服务类别，业务流和服务间依赖关系的面向服务的体系结构。例如，先前的单体系结构ERP项目分为订购服务和采购服务，物料服务和销售服务等。
4.微服务：可以理解为一个小型项目，例如先前的ERP大型项目，分为分为订购服务（订购项目），采购服务（购买项目），物料服务（物料项目）和销售服务（销售项目）以及服务之间的通话。三，此SSM项目引起的在线问题1.高峰时，CPU激增。
系统的每日峰值分为三个时间段：10点，13点和20点，以下是峰值的简要页面。2.一次性使用服务器cpu 3.一次性使用服务器请求号4. Rdis连接号（信息客户端）此未保存的屏幕截图，记得大约为600connected_clients：600 5. mysql请求屏幕截图四，检查过程和分析（1）检查思路根据服务部署和项目结构，检查从以下几个方面进行：（1）使用服务器：检查内存，cpu，请求数量等； （2）文件映像服务器：检查内存，cpu，请求数等； （3）定时器服务器：检查内存，cpu，请求数等； （4）redis服务器：检查内存，cpu，连接数等； （5）数据库服务器：检查内存，cpu，连接数等。
（2）在调查过程中，高峰后30分钟内：1.应用程序服务器的cpu和内存猛增，并且根本原因是CPU和内存暴涨的原因是请求数量太高，单个应用程序服务器达到了3,000多个； 2 .redis请求超时3.jdbc连接超时4.通过gc查​​看，发现FullGC在24小时内发生了152次。 5.再次查看堆栈，发现有一些线程阻塞和死锁jstat -l pid，也可以由VisualVM分析。
6.发现有2000个以上的线程请求无效资源（3）对线程的分析导致系统异常的主要因素（1）在高峰期间，请求量过高，导致应用程序服务器负载过高； （2）redis连接池已满，无法连接，无法从线程池获取连接（3）jdbc连接池已满，无法获得连接并超时（4）对象代码较大，例如添加对象对于列表集合，无法及时回收对象导致内存增加，并且频繁出现Full GC（5））Tomcat并发参数，jvm优化参数，jedis配置参数，jdbc配置参数不合理（6）请求数量未达到峰值且没有电流限制（7）资源连接未及时释放，例如redis连接，jdbc连接未及时释放，最终解决方案1.增加服务的使用率，进行流量峰值削减和分流。因为项目没有增加MQ，所以它只能使用硬负载并增加服务器水平扩展方法来实现流量峰值和流量分流2.优化jvm参数，如下所示优化参数JAVA_OPTS =“-server -Xmx9g -Xms9g -Xmn3g -Xss500k -XX：+ DisableExplicitGC -XX：MetaspaceSize = 2048m -XX：MaxMetaspace。