性能调优某大型银行的一个系统过程跟踪和记录

[-]

1. 一           问题调优跟踪
   1. 事务数1秒调整后4 秒对单測一支交易
   2. 事务平均数为478秒调整后15 秒对单測一支交易
   3. 事务数40秒调整后600秒对单測一支交易
   4. 事务数40秒调整后930秒对单測一支交易
   5. 事务数900TPS网络资源满100M网络混合交易
   6. 长时间压力測试后服务主机报错cannot set user id 资源临时不可用系统资源分配不够混合交易
   7. 集群环境中随着压力測试时间增长主机资源利用率逐渐下降调整后问题解决混合交易
   8. 集群环境存在队列等待集群管理通信出现队列stuck情况经打补丁包后解决混合交易
   9. 演练环境出现coredump现象--外围引发
   10. 演练环境出现GC无法回收资源现象--普元BPSserver引发
   11. 演练环境出现coredump现象之XA事务引发
2. 二           Last 总结
   1. 一         架构
   2. 二         操作系统
   3. 三         网络
   4. 四         应用
   5. 五         数据库
   6. 六         其他
3. 三           结束语
4. 四           附
   1. jconsole 监控stuck 线程
      1.   新建 session
      2.   进入session 并执行相关命令
   2. weblogic 监控stuck 线程

 

一、           问题调优跟踪

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左右；server端经观察发现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模式，并在同一台物理机是部署多个；以充分利用server资源；

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

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

分析：

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

解决方式：

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

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

 

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

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

分析：

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

         解决方式：

1．  添加keyword段索引

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

效果:

         依据stuck线程跟踪，沒有再发现此问题。

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

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

         分析：

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

解决方式：

更改全部代码，去掉全部读数据库的事务，对于单资源库的，假设不须要事务则也去掉事务；

效果:

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

 

二、           Last 总结

(一)         架构

1.        Weblogic最好不要採用集群方式，而採用单域单sever模式，并在同一台物理机是部署多个，以充分利用server资源；。

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 server装有X window。

安装 MobaXterm PersonalEdition 软件。

1)  新建 session

 

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

 

执行命令例如以下：

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

[root@localhost ~]# jconsole

 

 

 

2.     weblogic 监控stuck 线程

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