赞
踩
2013/1/3,启动压力测试后,事务约:1个左右每秒,经修改调整weblogic启动 JVM 参数 JAVA_OPTIONS,事务数据能达到4个左右;调整项如下:
1.调整weblogic启动 JVM 参数,在 JAVA_OPTIONS中增加: -Dweblogic.threadpool.MinPoolSize=200-Dweblogic.threadpool.MaxPoolSize=500
2.修改weblogic jdbc:domain->服务->数据源->loan->连接池->(初始容量:100, 最大容量:200, 最小容量:100)
2013/2/4, 1.VU用户并发能到达5个,事务平均数为4.78左右,增加再多VU,事务数不会增加,跟踪jrockit飞行记录,发现有争用现象,
javacommon.struts2.interceptor.SharedRenderVariableInterceptor 经排查是strus中有同步记录事务数,导致线程等待。经调整后,能提升到每秒15个事务左右;修改项如下:
1)修改easyloan.war\WEB-INF\classes\struts.xml:把如下内容注释掉:
<!--
<interceptors>
<interceptorname="sharedRenderVariableInterceptor"
class="javacommon.struts2.interceptor.SharedRenderVariableInterceptor"/>
<interceptor-stackname="customDefaultCrudStack">
<interceptor-refname="paramsPrepareParamsStack"/>
<interceptor-refname="sharedRenderVariableInterceptor"/>
</interceptor-stack>
</interceptors>
<default-interceptor-refname="customDefaultCrudStack"/>
--!>
2) 把 easyloan.war\WEB-INF\classes\struts.xml修改:
<constant name="struts.devMode" value="false"/> <!-- 开发模式设置为false--!>
3) 修改 easyloan.war\WEB-INF\classes\spring\applicationContext-service.xml如下:
default-autowire="byName" default-lazy-init="false" <!-- 惰性加载,调整参数为false --!>
4).向 easyloan.war\WEB-INF\classes\configuration.xml 文件的 <configuration>中增加如下:
<settings>
<settingname="lazyLoadingEnabled" value="false"/>
<settingname="aggressiveLazyLoading" value="fasle"/>
<settingname="defaultExecutorType" value="REUSE"/>
</settings>
2013/2/18, 前端LR显示只能达到并发用户约10个,tps到达40左右;服务器端经观察发现GC无法回收,并且后续tps下降到约5个左右;
Weblogic32位,JDK64位,经调整为weblogic32位和 weblogic 自带的32位JDK,内存为2G,性能提升约100倍(TPS:600,响应时间:0.37秒)
2013/2/20, 从开始执行性能测试以来,LR前端显示 tps最高到达40左右(除换成32位JDK), TPS无再增涨。
今天拷贝jrockit3364bit,和jrockit22 64bit,其中安装使用jrockit-jdk1.6.0_22-R28.1.1-4.0.1,性能明显提升,TPS最高到达930;
在测试过程中,由于网页存在图片文件传输,当有图片加载的页面过多,网络资源就占满。
解决方法:
1. 改变网络贷款为1000M网络
2. 对每个页面的图片能压缩就压缩;
3. 把很多页面加载原素放到首页加载,后续就不再加载资源;
解决方法:
修所有应用主机参数,即解决问题,之后再无此现象:
[loanapp@gdap1 ~]$ cat/etc/security/limits.conf |grep loanapp
#loanapp soft nproc 2047
loanapp soft nproc 10240
loanapp hard nproc 16384
loanapp soft nofile 65535
loanapp hard nofile 65536
2013/3/5,目前运行情况分析,并发 1200,每个 weblogic server 大约为 100 个并发。针对此情况,建议进行如下调整,然后进行对比测试。
-Xms4096m -Xmx4096m -Xns1024m
-Xgc:throughput
-XXgcthreads:32
-XX:+HeapDumpOnCtrlBreak-XX:+HeapDumpOnOutOfMemoryError
-Dweblogic.threadpool.MinPoolSize=100
相关参数解释,具体请参考 Jrockit参考手册:
针对内存消耗较大应用,增加Xns指定 Jrockit的Nursery区域,可以使存活时间短的
java对象回收完全。
针对于线程数较大情况,默认GC回收线程为 CPU核数(64) ,建议调小GC线程为32进行测试,这样可以降低进程的总线程数,降低线程数过大时的线程切换消耗。
在setDomainEnv.sh/中增加如下启动参数:
JAVA_OPTIONS="${JAVA_OPTIONS}-Xgc:throughput -XX:+HeapDumpOnCtrlBreak -XX:+HeapDumpOnOutOfMemoryError-XXgcthreads:32"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.threadpool.MinPoolSize=100"
2013/3/5日Weblogic控制台的队列长度存在排队,数值只增加不会减少,无业务时,队列数值也不会减少。
分析发现这些排队请求不影响正常的业务请求,存在排队时,Weblogic控制台的“暂挂用户请求计数”数值一直为 0,表明正常业务请求都能正常处理。
检查Weblogic官方公布的补丁情况,发现此问题为Weblogic10.3.6的一个bug,这些排队请求为Weblogic内部的RMI请求,此BUG 信息如下:
Bug 15839280 : [WLS10.3.6] QUEUE LENGTH COUNT INCREASES OVER TIMEAND NEVER REDUCES
修复补丁为:Patch: 15839280
将Weblogic产品打上此补丁,压测观察,队列能够正常收回。
解决方法:
1. Weblogic1036-Patches
2. 不使用weblogic集群模式,采用单域单sever模式,并在同一台物理机是部署多个;以充分利用服务器资源;
2013/3/11,今天约200人同时在线做操作演练环境出现coredump,应用主机出现线程挂起状态。
分析:
经跟踪,是我们在调用外围系统时,如果外围(出现异常或通信故障)长时间不返回,我们的应用就一直等待,当大量并发调用外围,会导致大量线程挂起,导致长时间GC无法回收,随后出现coredump;
解决方案:
1. 临时先屏蔽外围,此现象就不再出现;
2. 调整接口模块超时时间设置为15分钟,应用线程退出;
2013/3/12,今天约400人同时在线做操作,在压力测试时(2013/3/9),BPS服务器已经存在瓶颈,当业务员登陆系统后,查待办;当并发量大时,会导致数据库资源过高,长时间不返回待办事项,最终导致GC长时间无法回收资源;而在演练时2013/3/12晚上,当大量人员查待办时,此现象又出现,而且页面长时时间无返回,业务人员上报也上报此问题。
分析:
经跟踪BPS应用和数据库发现一查待办的慢SQL,关键字段未加索引,且SQL写法需调整;
解决方案:
1. 增加关键字段索引
2. 优化SQL写法,提高查询效率;
效果:
根据stuck线程跟踪,没有再发现此问题。
2013/3/13,今天约12000人左右同时在线做操作演练环境出现coredump,应用主机出现线程挂起状态。
分析:
由于在我们的应用采用分库方式,分为贷前和贷后库,为了保证写事务一致性,采用了XA事务方法。而我们在写的过程中,把读数据库也启用了XA事务,最后引大大量事务未提交,占用大量JVM资源,最后出现coredump。
解决方案:
更改所有代码,去掉所有读数据库的事务,对于单资源库的,如果不需要事务则也去掉事务;
效果:
接下来几点再未出现coredump现象;
1. Weblogic最好不要采用集群方式,而采用单域单sever模式,并在同一台物理机是部署多个,以充分利用服务器资源;。
a) 虽然集群可以减少部署工作量,降低参数修配置的工作量,方便统计计数等优点。
b) 缺点集群存在集群中节点同步信息的问题,如果集群节点多,主机管理各节点资源还会消耗一部份资源。根据以上经验,有可能会出现;
2. Weblogic的下,如果在业务逻辑性上,为了要保证增、删、改的事务一致性,启用了XA事务,那么一定记得不要不是所有的事务都需要用到XA事务,不使用XA事务:
a) 查询不需要使用XA事务
b) 如果某些数据只存在于一个数据源中,同样也不需要使用XA事务
注:XA事务是等待所有的事务成功后再算成功,否则回退,那么就要保证过程的持续状态,资源就得不到释放,JVM内存中事务多了,协调各事务资源也就多了,从而引发粘滞线程,最终导致处理能力大幅度下降,最严重情况是导致JVMdown机,如第一章节的11个问题就是最好的例证;
3. 架构下的各组件的基本配置参数需要进行调整,那么就需要对各组件非常了解熟悉才能调整,如struts spring 等组件配置参数要知道详细配置组合,需求仔细研究各组件特性。
操作系统与JDK的比配关系要经过不断测试才能找出最优的配合;
操作系统相应参数是否按管方进行了调整,但最好能懂得部份内核机制,如调整TCPbuffer大小,内存页大小等;
网络贷款资源要注意监控,TPS上不去看是否存在带宽资源问题;
注意应用程序内部算法是否存在某种同步机制等算法,一般在保证同步的情况下,并发性能都不是太好;
程序中是否存在Block现象,如事务同步算法等,此会导致在并发时出现队列等待现象,最终TPS上不去;
数据的存储IO,分库,SQL索引等优化方法,这需要单独的优化知识,必要时,找专业DBA配合;最好自己也学习一下Oracle 的体系结构,才知道大致出现在什么地方的问题;
性能测试时,挑选的常用且较为复杂的交易进行性能测试,但无法cover所有的交易,那么可能存在这种现象:
1. 某个业务上,用得少,性能测试时没有挑选,但由于SQL写得有问题,长时间操作(读写)数据库,导致资源无法释放,就有可能导致JVM dump掉;
2. 某一程序,同样性能测试没有做,JAVA程序在处理业务逻辑时是正确的,但申请的对象总是没有释放,长时间下去,多人多次长时间操作涉及此程序模块,大量对象没有释放,JVM程度占满,最终出现coredump。
所以对于整个应用系统来说,不能完全相信性能测试结束了,调优也就结束了。根据许多项目印证,并非如此。后续还需要定期进行应用巡检,包括操作系统运行记录、应用运行记录、中间件运行记录、数据库运行记录,用以发现边角处那些致命的小问题。
此文章并非讲每个细节如何调整,而只是个人习惯作个笔记而已。不喜勿喷,调优是个很大的工程,如JVM启动参数应该使用哪些特性、操作系统应该调整哪些系统参数、架构中组件的特性应该怎么调、数据库应该怎么调优,这些话题都太大,每个都要理解基本原理才能能给出调优意见;如我在没有考Oracle OCP 之前,以为Oracle调几个参数就叫优化了,现在理解完全不一样,磁盘特性、操作系统特性、Oracle相关特征,如它的日志、页、Buffer、SQL语法写法、索引如何建立,是否会产生分裂,这些都会影响到性能。而这些知识在网上都可以找到相应的文章,或是官方文档有详细说明。在某种架构下,哪些特性组合在一起才是最优的,需要不断的积累和前辈们的经验,多看看技术原理的书籍或是官方文档,才真正有利于调优;
保证Linux 服务器装有X window。
安装 MobaXterm PersonalEdition 软件。
执行命令如下:
[root@localhost ~]# export DISPLAY=192.168.33.1:0.0 [root@localhost ~]# jconsole
|
由于时间原因,当时记录的粘滞线程截图没有了,下次有机会我再补充上;
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。