一、           问题调优跟踪

1.     事务数1/秒，调整后4 /秒(对单测一支交易)

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）

2.     事务平均数为4.78/秒，调整后15 /秒(对单测一支交易)

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>

3.     事务数40/秒，调整后600/秒(对单测一支交易)

2013/2/18, 前端LR显示只能达到并发用户约10个，tps到达40左右；服务器端经观察发现GC无法回收，并且后续tps下降到约5个左右；

Weblogic32位，JDK64位，经调整为weblogic32位和 weblogic 自带的32位JDK，内存为2G，性能提升约100倍（TPS:600,响应时间：0.37秒）

4.     事务数40/秒，调整后930/秒(对单测一支交易)

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;

5.     事务数900/TPS，网络资源满（100M网络）(混合交易)

在测试过程中，由于网页存在图片文件传输，当有图片加载的页面过多，网络资源就占满。

解决方法：

1.      改变网络贷款为1000M网络

2.      对每个页面的图片能压缩就压缩；

3.      把很多页面加载原素放到首页加载，后续就不再加载资源；

6.     长时间压力测试后，服务主机报错：“cannot set user id: 资源暂时不可用，系统资源分配不够”(混合交易)

解决方法：

修所有应用主机参数，即解决问题，之后再无此现象：

[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

7.     集群环境中随着压力测试时间增长，主机资源利用率逐渐下降，调整后问题解决(混合交易)

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"

8.     集群环境存在队列等待，集群管理通信出现队列stuck情况，经打补丁包后解决；(混合交易)

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模式，并在同一台物理机是部署多个；以充分利用服务器资源；

9.     演练环境出现coredump现象--外围引发

2013/3/11，今天约200人同时在线做操作演练环境出现coredump，应用主机出现线程挂起状态。

分析：

经跟踪，是我们在调用外围系统时，如果外围(出现异常或通信故障)长时间不返回，我们的应用就一直等待，当大量并发调用外围，会导致大量线程挂起，导致长时间GC无法回收，随后出现coredump；

解决方案：

1.      临时先屏蔽外围，此现象就不再出现；

2.      调整接口模块超时时间设置为15分钟，应用线程退出；

10.             演练环境出现GC无法回收资源现象--普元BPS服务器引发

2013/3/12，今天约400人同时在线做操作，在压力测试时(2013/3/9)，BPS服务器已经存在瓶颈，当业务员登陆系统后，查待办；当并发量大时，会导致数据库资源过高，长时间不返回待办事项，最终导致GC长时间无法回收资源；而在演练时2013/3/12晚上，当大量人员查待办时，此现象又出现，而且页面长时时间无返回，业务人员上报也上报此问题。

分析：

经跟踪BPS应用和数据库发现一查待办的慢SQL，关键字段未加索引，且SQL写法需调整；

         解决方案：

1．  增加关键字段索引

2．  优化SQL写法，提高查询效率；

效果:

根据stuck线程跟踪，没有再发现此问题。

11.              演练环境出现coredump现象之XA事务引发

2013/3/13，今天约12000人左右同时在线做操作演练环境出现coredump，应用主机出现线程挂起状态。

         分析：

由于在我们的应用采用分库方式，分为贷前和贷后库，为了保证写事务一致性，采用了XA事务方法。而我们在写的过程中，把读数据库也启用了XA事务，最后引大大量事务未提交，占用大量JVM资源，最后出现coredump。

解决方案：

更改所有代码，去掉所有读数据库的事务，对于单资源库的，如果不需要事务则也去掉事务；

效果:

接下来几点再未出现coredump现象；

二、           Last 总结

(一)         架构

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语法写法、索引如何建立，是否会产生分裂，这些都会影响到性能。而这些知识在网上都可以找到相应的文章，或是官方文档有详细说明。在某种架构下，哪些特性组合在一起才是最优的，需要不断的积累和前辈们的经验，多看看技术原理的书籍或是官方文档，才真正有利于调优；

四、           附

1.     jconsole 监控stuck 线程

保证Linux 服务器装有X window。

安装 MobaXterm PersonalEdition 软件。

1)  新建 session

2)  进入session 并执行相关命令

执行命令如下：

[root@localhost ~]# export DISPLAY=192.168.33.1:0.0 [root@localhost ~]# jconsole

2.     weblogic 监控stuck 线程

由于时间原因，当时记录的粘滞线程截图没有了，下次有机会我再补充上；