一、 问题调优跟踪
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 线程
由于时间原因，当时记录的粘滞线程截图没有了，下次有机会我再补充上；