你好,根据你提供的内容,这是一篇关于线上高并发调优的文章。文章主要介绍了项目的架构、单体架构项目的概念、本SSM项目引发的线上问题以及排查过程和分析。如果你有具体的问题或者需要更多的信息,可以告诉我哦。
在秒杀活动进行后的30分钟内,我们发现了一些系统异常现象。经过分析,我们找到了以下几个主要原因:
1. 请求量过高:在秒杀活动期间,请求量迅速增加,导致服务器负载过高。单台应用服务器的CPU和内存使用率均达到了3000多。
2. Redis连接超时:由于请求过多,Redis连接池中的连接被耗尽,导致无法获取到连接。
3. JDBC连接超时:同样的原因,JDBC连接池中的连接也被耗尽,无法获取到连接或发生超时。
4. Full GC频繁发生:通过GC查看,发现在24小时内,Full GC发生了152次。这可能是因为存在大对象代码,如向list集合中不停添加对象,不能及时回收对象导致内存增加,从而引发频繁的Full GC。
5. 线程阻塞和死锁:堆栈中有一些线程显示为阻塞和死锁状态。
6. 无效请求过多:有2000多个线程请求了无效资源。
综合以上分析,我们认为本次系统异常的主要原因包括:
1. 秒杀活动期间请求量过高,导致服务器负载过高;
2. Redis和JDBC连接池中的连接不足;
3. 存在大对象代码,导致频繁的Full GC;
4. Tomcat并发参数、JVM优化参数和Jedis配置参数不合理;
5. 未对请求量进行削峰和限流;
6. 资源连接未及时释放。
为了解决这些问题,我们提出了以下解决方案:
1. 增加应用服务器实例,实现流量削峰和分流。由于项目中未使用消息队列(MQ),因此只能采用硬负载的方式,通过增加服务器实例来实现流量削峰和流量分流。
2. 优化JVM参数。经过调整,我们将以下参数设置为优化后的值:
```java
JAVA_OPTS=“-server -Xmx9g -Xms9g -Xmn3g -Xss500k -XX:+DisableExplicitGC -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -Dfile.encoding=UTF8 -Duser.timezone=GMT+08”
```
关于这些JVM参数的优化,我们将在后续文章中进行详细分析。官方建议和实际应用经验可能会有所不同。
3. 优化Tomcat并发相关参数。主要包括两方面:一是调整线程池大小;二是调整连接超时时间。具体调整方法需要根据实际情况进行选择。
本文主要从实战角度出发,与大家分享了一次线上高并发调优的整个闭环过程。首先,我们对问题进行了识别和定位,然后分析原因,并提出了解决方案。在实施解决方案的过程中,我们对系统进行了监控调优,最终达到了优化效果。
一、问题识别与定位
1. 系统在高并发场景下出现性能瓶颈,响应时间较长,用户等待时间较长。
2. 通过监控系统资源发现,CPU、内存等资源使用率较高,但线程数并未明显增加。
3. 对系统进行压力测试,发现在高并发场景下,请求无效资源的次数较多。
二、问题分析与解决方案
1. 修改bio协议为nio2:NIO(New I/O)是Java的一种新的I/O模型,相比传统的BIO(Blocking I/O)模型,NIO具有更高的性能和更低的延迟。因此,我们将系统的IO模型从BIO改为NIO2。
2. 根据服务器配置、业务场景和业务流量等合理设置相关参数,尽量达到最优:例如,调整线程池大小、连接数等参数,以提高系统处理能力。此外,还可以根据实际情况对缓存大小、连接超时时间等参数进行调整。
3. 代码优化:包括优化大对象、及时释放未及时释放的对象和连接资源等。
4. 解决000多个线程请求无效资源问题:通过增大缓存容量,降低访问冷数据的可能性。具体操作如下:
在conf/context.xml中增大缓存:
```xml
cachingAllowed = "true";
cacheMaxSize = "102400";
```
三、最终优化结果
经过几天观察,系统性能得到了显著提升,基本监控、GC、抽样器cou和内存、CPU、内存等方面都有所改善。
四、总结
1. 本篇文章从实战角度,从问题识别、问题定位、问题分析、提出解决方案、实施解决方案、监控调优后的解决方案和调优后的观察等角度来与大家一起交流分享本次线上高并发调优整个闭环过程。由于篇幅限制,部分细节和优化手段未在本篇文章中提及。
2. 虽然解决了该问题,但从长远来看,该单体项目仍存在很大的问题和隐患,如前后端紧耦合未分离、秒杀业务未进行局部并发架构调整、未隔离导致秒杀业务可能瘫痪的风险、未做流量削峰和流量限流等。同时,redis也未做高可用集群。