基于SSM架构的商城项目,遇到cpu暴增,业务瘫痪,全组慌了。。。
大家好,我是D哥
点击关注下方公众号,Java面试资料 都在这里
对于线上系统调优,它本身是个技术活,不仅需要很强的技术实战能力,很强的问题定位,问题识别,问题排查能力,还需要很丰富的调优能力。
本篇文章从实战角度,从问题识别,问题定位,问题分析,提出解决方案,实施解决方案,监控调优后的解决方案和调优后的观察等角度来与大家一起交流分享本次线上高并发调优整个闭环过程。
# 项目简要情况概述
该项目为基于SSM架构的商城类单体架构项目,其中有一个秒杀重磅模块,如下为当前线上环境的简要架构部署图,大致描述一下:
(3) 调用逻辑:下图为简要调用逻辑
# 何为单体架构项目
4. 微服务:可理解为一个个小型的项目,如之前的ERP大型项目,划分为订单服务(订单项目),采购服务(采购项目),物料服务(物料项目)和销售服务(销售项目),以及服务之间调用
# 本SSM项目引发的线上问题
该系统每天秒杀分为三个时间端:10点,13点和20点,如下为秒杀的简要页面
3.单台运用服务器请求数
这个未保存截图,记得是600左右
connected_clients:600
# 排查过程及分析
根据服务部署和项目架构,从如下几个方面排查:
(5)db服务器:排查内存,cpu,连接数等;
(三)造成本次系统异常主要因素分析
(7)资源连接未及时释放,如redis连接,jdbc连接未及时释放
# 最终解决方案
由于该项目未增加MQ,因此只能采用硬负载,增加服务器水平扩展方式来实现流量削峰和流量分流
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参数的优化,jvm理论是怎样的,官方建议是怎样的,实战是怎样的,将在下篇文章中分析。
(1)修改bio协议为nio2 (2)根据服务器配置,业务场景,业务流量等合理设置相关参数,尽量达到最优
由于涉及到安全性问题,这里不列出
5. 代码优化
(2)优化未及时释放的对象和连接资源
在conf/context.xml增大缓存
<Resource
cachingAllowed = "true"
cacheMaxSize = "102400"
/>
# 最终优化结果
3. 抽样器cou和内存
# 总结
1. 本篇文章从实战角度,从问题识别,问题定位,问题分析,提出解决方案,实施解决方案,监控调优后的解决方案和调优后的观察等角度来与大家一起交流分享本次线上高并发调优整个闭环过程,当然,由于篇幅的限制,有些细节和优化手段未在本篇文章中提及;
2. 虽然解决了该问题,但是从长远来看,该单体项目任然存在很大的问题和隐患,下面随便举几个:
(5)redis未做高可用集群
有不少同学问D哥,大厂面试官到底喜欢问什么?想进大厂镀金。因此,D哥特意邀请了华为、腾讯、阿里的朋友进群,与大家一起交流经验,增长技术。
有兴趣入群的同学,可长按扫描下方二维码,一定要备注:城市+昵称+技术方向,根据格式备注,可更快被通过且邀请进群。
▲长按扫描