连载-从一个项目看系统优化工程(7)

中间件优化(2)

优化项目组再次和开发商做了沟通,建议开发商对应用进行分拆,把12实例的应用拆分为两个集群,将应用系统也分拆为两部分,分别部署在两个集群中。开发商经过评估后认为这个优化方案作为终极优化的方案是可行的,不过工作量很大,需要做严格的测试,而且对于这套已经全国各省推广的系统,有三十多家单位在使用,整体的优化成本过高。因此这个方案对于开发商来说是无法接受的。考虑到这套系统已经在三十多个单位运行了一年多,应用分拆相当于一次大版本升级,成本过高。因此优化项目组马上抛出已经准备好的第二方案WEBLOGIC升级为64位,具体升级方案是保留版本号不变,只是改为64位的系统。这个方案得到了开发商的积极响应,他们认为可以马上在测试环境中部署一套系统,开发商和优化团队联合进行测试。

WEBLOGIC升级到64位后,JVM参数没有做调整的情况下,开发商也感受到应用性能有所提高,把JVM的堆大小调整为4GB后,性能提升就更明显了,大量的应用模块的响应时间都有大幅度的提升,有些以前经常报错的模块也不报错了,只是还是存在大量响应时间几十秒甚至几分钟模块。开发商建议立即升级WEBLOGIC,以更好的渡过这个月底的高峰期。按道理在整体优化方案没出来之前就做调整是优化工作中的大忌,不过由于开发商与业务部门的压力过大,于是优化项目组同意了单独实时WEBLOGIC升级的可行性进行评估。

weblogic的瓶颈得到改善后,后端数据库的压力也会加大,如果此时数据库方面也存在较为严重的问题,那么一旦前端WEBLOGIC的吞吐能力提升,则后端数据库的问题就会被放大。因为这套系统目前的整体情况我们摸的还不是很透,所以这种只升级应用服务器的做法还是让优化项目组不敢轻易下决心。虽然从前面的分析来看,数据库服务器的负载并不高。

优化项目组建议召开一个开发商、业务部门、运维单位参加的四方协调会,就本次升级可能的效果以及风险做一个通报,最后大家集体决策,是否进行此项升级。在本次会议上,业务部门和运维单位都表示建议立即升级微博logic,并表示哪怕升级后出现了问题,大不了就回退,不会影响他们对优化项目的期待。

WEBLOGIC升级后,就迎来了优化项目组进驻现场后的第一个业务高峰。每个月的25号开始到下个月的5号这段时间由于存在大量的结算与统计业务,整个系统的负载都比较高,同时也是问题频出的时候。这个时间段内,只要不宕机,运维单位就会感到十分庆幸了。只要大批量的统计报表不出错,业务人员也就不用整天加班处理了。这个月底系统状态十分正常,数据库没出现宕机,业务部门也感觉到很多以前经常出错的模块也没报错,虽然总体性能的提升还不太感受得到,不过这个月的结算和统计报表基本上是顺利的。

在这种形势一片大好之下,优化项目组却高兴不起来,WEBLOGIC有所改善后,数据库服务器的问题越来越严重了。

                       

连载-从一个项目看系统优化工程(7)

   

Load Profile上看,系统的负载确实有所增加,看上去效果不错。不过从TOP EVENT上看,数据库系统已经处于十分危险的状态了。

连载-从一个项目看系统优化工程(7)

共享池的问题已经暴露出来了,而且已经相当的严重了。看样子后面的优化重点要放在数据库上了。

连载-从一个项目看系统优化工程(7)》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/151.html