weblogic压力测试中的性能调试手册要点

1.1.1 Oracle数据库设置1.【PGA】24602.【SGA】shared_pool_size=48,803.【SGA】高速缓存区：24,404.【SGA】java池：300（8）5.会话1501000.6.游标300100 Jar包设置：1、Log4j删除日志，加“#”2、DynamicDao删除system.Out SQL1.1.3 Weblogic设置 内存大小setDomainEnv.cmd if %JAVA_VENDOR%=Sun (set WLS_MEM_ARGS_64BIT=-Xms256m -Xmx512mset WLS_MEM_ARGS_32BIT=-Xms256m -Xmx1524m 域JTA 配置超时秒数:360事务超时数100.1 服务器上资源的最大请求数（每个服务器所允许的最大并发资源请求数500）事务超时数100服务器:接受预备连接:600 域Web应用程序设置 JDBC连接池域服务JDBC数据源连接池1、语句缓存大小 1002、不支持全局事务3、初始容量:54、最大容量:100（已经修改为500）5、容量增长:56、收缩频率:4507、语句超时:10008、非活动连接超时100 部署监视部署监视JDBC Servers连接池配置服务JDBC数据源配置连接缓冲池 Server管理控制服务器AdminServer（管理）控制服务器AdminServer（管理） Java虚拟机内存回收服务器AdminServer（管理）选中监视性能垃圾回收内存（Java 虚拟机内存利用率统计信息） 监视JDBC0 监视JTA1 服务器参数调整（接受预备连接:600）服务器AdminServer（管理）选中调整2 最长线程阻塞时间服务器AdminServer（管理）选中超载3 BEA- Closing socket as no data read from it1、Set the parameter -Dweblogic.client.socket.ConnectTimeout=XXX, in the start-up script of the server which you are seeing this issue under JAVA_OPTIONS Note: Where XXX is the value in ms.Example:-Dweblogic.client.socket.ConnectTimeout=5002、Server - Protocols (tab) - HTTP (sub-tab) - Duration（持续时间）4 BEA- Free memory in the server. There is danger of OutOfMemoryErrorThanks for the Hint.I found that changing the Low Memory Sample Size from 10 to 120 solved my problem.When WebLogic uses JRockit, it know when the GC runs and cleans up memory. It samples the free heap at this time (because all of the garbage has been collected and memory is as empty as it is going to get) and if the average over the hour is Servers - the server you wish to change - Configuration - TuningAfter making the change you have to restart the server.It also a good idea to check that the change worked (I lost my change during the restart somehow the 1st time I did it).5 转1常用weblogic性能调优方法常用weblogic性能调优方法 (2007-05-22 12:23:57) 1.设置最大线程(并发)数量myserver|Configuration|Monitoring|performance可以观察整体性能Idle Threads数量少,Queue Length比较大说明存在多并发,而且CPU资源比较空闲需要增加线程数量,具体方法 myserver|Configuration|Monitoring|performance|General Monitor all Active Queues. 调整当前Thread Count个数,一般量大得可以设置到100。【备注版本9.0：weblogic.kernel.default其实是一个weblogic的核心参数，设置的值就是weblogic用来响应客户端请求的线程数量。也就是说，一个用户登陆应用系统进行某操作，则WebLogic将从weblogic.kernel.default中分配一个线程给该用户。默认情况下，这个参数值是40。比如对大的企业应用，同一时间登陆操作系统的用户非常多，则40个线程就显得太少了。同时，如果你的应用程序设计得不好，造成很多操作速度非常慢，因为WebLogic要等待你一个操作完成之后，才进行线程的回收处理，如果同一时间有很多线程在执行非常慢的操作，这也会引起线程数量不够的问题。 具体的表现就是在WebLogic的控制台的myserver中的Monitoring页面下的Performance页面中，Queue Length显示不是等于0，图像可能是一个曲线。Queue Length这个参数的意义就是“在等待队列里的请求数”。正常情况下，应该是0，图像是一个水平的横线。也就是没有客户端的请求会等待，都能及时的得到系统的处理。 如果确认是因为用户过多的原因需要增大weblogic.kernel.default参数的值，我们怎么修改？ 进入WebLogic控制台左边窗口的mydomainservers点击myserverConfigurationGeneral点击Advanced Options的Show链接最下面的Configure Execute Queues 链接weblogic.kernel.Default链接Thread Count参数。的却是隐藏的比较深。修改Thread Count的值，然后重启WebLogic就可以生效了。】【备注版本10.0：根据客户的要求，我们在webblogic10上测试wicket框架的性能。需要设置并发线程数设置。根据网上资料，需要在config.xml的server部分配置修改，如下： AdminServer default 200 400 true 请不要画蛇添足，否则，webapplications跑不起来的，配置execute-queue的基本属性就行了。我中途也吃过这个亏。】2.设置内存 在启动脚本中 set MEM_ARGS=-Xms512m -Xmx1000m 即最小内存和最大内存.不宜太小也不宜太大3.最大socket连接数(出现connection refused可以增加次数量)myserver|Configuration|Tuning |Accept Backlog一般比Thread Count稍微大一点4.连接池得最大最小格式设置成相同,并且不少于50个(一般和Thread Count差不多). 5.x86PcSvr环境下采用jrockit(BEA专门针对x86做了性能优化得JDK)性能有显著提高20%.以下假设d:beajrockit81sp1_141_03是jrockit的路径。l 如果启动采用startETS.cmd脚本则修改以下环境变量：set JAVA_HOME=d:beajrockit81sp1_141_03set JAVA_VM=-jrockitset MEM_ARGS=-Xms512m -Xmx1000ml 如果启动采用startWebLogic.cmd脚本则：在call %WL_HOME%commonbincommEnv.cmd前后的语句成如下格式：set JAVA_VENDOR=BEAset JAVA_HOME=d:beajrockit81sp1_141_03set JAVA_VM=-jrockitcall %WL_HOME%commonbincommEnv.cmdset MEM_ARGS=-Xms512m -Xmx1000m6 转2常用weblogic性能调优方法1、性能测试过程中出现问题的解决网络链接被自动断开性能测试过程中当并发达到500时，出现下图中的大量错误，错误率在25左右，如果并发量加大，错误率更高。 7 BEA WebLogic JRockit的使用和性能调优一JRockit调优简介 JRockit是一个自适应的JVM，它能够自动调整自己去适应底层硬件，因此对它的调优主要集中在一些需要人工干预的参数上，比如说：需要划分多少RAM给JRockit使用等。JRockit有一组非标准的-X启动选项，我们可以用它来调节JVM。JRockit有两组主要的子系统可以被优化-内存管理系统（包括垃圾回收）和线程系统。在内存管理子系统方面，有很多调优的工作可以做。 二Tuning WebLogic JRockit JVM 1设置初始堆尺寸 可以通过-Xms:m来设置初始堆大小，如果-Xmx的值小于128MB，则-Xms缺省取值为16MB；如果-Xmx设置大于128MB，则-Xms缺省值为物理内存的25%，最大不超过64M。例子：$java -Xgc:gencon -xms:64m -Xmx:64m myClass2设置最大堆尺寸可以通过-Xmx:m来设置最大堆尺寸。在IA32构架下，由于操作系统给每个进程的最大内存寻址空间为1.8G，因此最大堆尺寸不能超过1.8G。在IA64构架下，就没有1.8G的限制。如果你的JAVA应用程序在运行时出现了Out of memory的错误，你就需要调大最大堆尺寸。如果没有设置最大堆尺寸，则缺省值为：1 如果设置了-Xgc:gencopy，由最大堆尺寸是min400, 物理内存*75%；2 如果没有设置-Xgc:gencopy，由最大堆尺寸是min1536, 物理内存*75%；最好手工把最大堆尺寸设置为物理内存（1024M）的75%：$java -Xgc:gencon -xms:64m -Xmx:768m myClass3设置Nursery的尺寸可以使用-Xns:来设置Nursery的尺寸，我们要在保证垃圾回收停顿时间（garbage collection-pause）尽可能短的同时，尽量加大Nursery的尺寸，这在创建了大量的临时对象时尤其重要。缺省值为：1 对于-Xgc:gencopy，缺省的Nursery大小为320KB/CPU，对于10个CPU的系统来说，Nursery大小为3200KB（3.2M）2 对于-Xgc:gencon，缺省的Nursery大小为10M/CPU，对于10个CPU的系统来说，Nursery大小为100M4定义内存空间的清理时机可以使用-Xcleartype:来定义已经被垃圾回收的内存空间在什么时候可以被清理，支持以下三种方式：1 gc，在垃圾回收的同时清理内存；2 local，在分配了一块thread-local区域时清理内存，仅在把参数-Xallocationtype设置成local时才有用；3 alloc，在这块内存被分配给其它对象时清理。在IA64上目前还不支持。缺省值为：1 IA32上缺省值为alloc2 IA64上缺省值为gc5定义线程分配的类型可以使用-Xallocationtype:来定义线程分配的类型。1 global，在最大堆尺寸比较小时（小于128M）或者应用程序大量使用了线程时使用。2 local，在最大堆尺寸比较大时（大于128M）或者应用程序少量使用了线程时使用。缺省值：1 如果设置了-Xgc:gencopy，缺省值为global2 如果设置了-Xgc:siglecon，-Xgc:gencon和-Xgc:parallel，缺省值为local6定义线程栈尺寸可以使用-Xssk|Km|M来定义线程栈大小。最小线程尺寸定义如下：1 thin threads：最小线程栈尺寸为8K，缺省为64K；2 native threads：最小线程栈尺寸为16K如果-Xss设置小于最小值，则自动使用最小值。缺省值：1 IA32系统，WIN32：64K，LINUX32：128K2 IA64系统，WIN64：320K，LINUX64：1M 二Basic Tuning Tips and Techniques 尽管JRockit提供了一组缺省的OOTB配置选项，但最好根据实际应用情况来对JRockit作一些调整。1决定你要在哪方面调优要考虑的因素有：1 要为JRockit分配多少内存空间；2 你要调优的目的是什么，是要得到更好的响应性还是更好的性能；2设置堆尺寸对于堆尺寸来说，当然是越大越好了。如果设得不够大，就会造成Out-of-memory和内存分页错。如果同时运行了多个应用程序，建议把最小和最大堆尺寸设置成一样大。3在高响应性方面的调优 要得到更好的响应性能，应该设置1 使用并发垃圾回收器。-Xgc:gencon2 设置初始和最大堆大小。-Xms512m，-Xmx768m，由于使用了并发垃圾回收器，所以堆大小不会造成长时间的等待。3 设置nursery尺寸。如果用到了大量的临时对象，则需要适当的调大nursery尺寸。调大nursery尺寸会导致垃圾回收的停顿时间加长，因此要注意，确保垃圾回收的停顿时间在可忍受的范围内，这个停顿时间可以通过设置-Xgcpause来查看。4在高性能方面的调优如果要得到更好的性能，你应该：1 选用并行垃圾回收器，由于并行垃圾回收器不使用nursery，因此你不必再设置-Xns，方法是加上-Xgc:parallel2 把初始和最大堆尺寸设置调到尽可能的大。方法是-Xms512m, -Xmx768m。5分析垃圾回收和停顿时间1 使用-Xgcreport生成报表，显示垃圾回收的统计信息，从中可以看出你是不是最有效地使用了垃圾回收器。2 使用-Xverbose:memory来显示在运行期间每一次垃圾回收的停顿时间。本选项仅用于调试，会产生大量的控制台输出。6调整线程选项当大量地使用了线程时（超过100个），需要调整线程选项：1 使用thin线程选项。-Xthinthreads。瘦线程模式在LINUX下非常有效。注意：瘦线程在JRockit中只是一个试验选项，不推荐广泛使用；2 关闭本地分配线程的选项。-Xallocationtype:global。每个本地线程区都要消耗大约2K的内存，如果大量地使用了线程，本地线程不但会造成内存空间浪费，而且还会造成堆碎片。使用全局线程机制会减少堆碎片，但在内存分配方面速度要慢一些。7分析并改善应用程序设计找出瓶颈方法：1 使用Intel VTune工具；2 使用-Xjvmpi:allocs=off,monitors=off,entryexit=off选项。三Command Line Options by Name 启动JRockit时，可以带一些-X选项，这些选项是非JVM标准的，专门用于配置JRockit的性能。选项 描述 -X显示扩展Java选项-Xallotype-Xallocationtype可取值global和local，定义使用本地线程还是全局线程。-Xbootclasspath指定类搜索路径，可以是ZIP和JAR文件，以；或：分隔-Xcleartype定义内存清理时机，可取值gc, local, alloc。gc表示在垃圾回收时清理内存；local表示时分配一块local线程区时清理；alloc表示内存区要被分配给其它对象时清理-Xgc选择要使用的垃圾回收器的类型，可取值：gencopy：generational copyingsinglecon：single spaced concurrent，单空间并发gencon：generational concurrentparallel：parallel如果-Xmx小于128M，缺省使用gencopy，否则使用gencon-Xgcpause打印由垃圾回收器造成的停顿时间-Xgcreport打印垃圾回收报表-Xjvmpi是否允许JVMPI事件，这些事件有：entryexit（缺省ON）allocs（缺省ON）monitors（缺省ON）arenasdelete（缺省OFF）-Xmanagement激活JVM中的管理服务器，在JVM的管理控制台能连接到它之前，必须先激活。-Xms设置初始堆大小，单位有K、M、G-Xmx设置最大堆大小，单位有K、M、G-Xnativethreads使用本地线程系统，这是缺省选项-Xnoclassgc禁止对类作垃圾回收-Xnohup告诉JRockit，忽略CTRL_LOGOFF_EVENT和SIGHUP事件-Xns设置nursery尺寸，单位有K、M、G-Xss设置线程栈尺寸，单位有K、M、G-Xthinthreads使用JRockit的高性能线程系统，在IA64上不可用。-Xverbose让JRockit打印更多的信息，可选的参数有：codegen、cpuinfo、gc、load、memory、Opt-Xverify作完整的bytecode一级的校验四用JRockit8.1中的Method Profiler调优WebLogic 1关于Method Profiler工具 BEA WebLogic JRockit 8.1提供了一个Profiling工具：Method Profiler来调优WebLogic应用。2利用Method Profiler调优WebLogic应用JRockit 8.1所带的Method Profiler工具能够将所有在JRockit Java虚拟机上执行的成员方法的调用次数、执行的总时间和每次调用的执行时间都统计出来，如图1所示。这样的功能一来可以让我们对跑在WebLogic上的应用进行tuning（代码级的），二来也大大方便了我们确定系统瓶颈在何处。这也可以说是JRockit JVM相对于其他JVM在功能上的一大优势。在一次对WebLogic Server 8.1的压力测试中，对一组包含了CMP特性的样本进行压力测试时，就利用JRockit的Method Profiler诊断出了系统的瓶颈所在，现介绍如下。CMP这组样本中原先对CMP Entity Bean的操作除了用ejbCreate插入一条记录之外，紧跟着用setName方法设置其name属性，即UPDATE其对应数据库记录中name域的值，代码如下：public void ejbCreate() /Stateful4CMPBean中的方法throws CreateExceptiontryContext ctx = new InitialContext();SheepHome home = (SheepHome)ctx.lookup(Sheep);Sheep sheep = null;int x = getNextId(); / getNextId()也包含对数据库的操作sheep = home.create(x);if(sheep != null)sheep.setName(sheep1.concat(String.valueOf(String.valueOf(x);m_strMsg = create sheep.concat(String.valueOf(String.valueOf(x); elsem_strMsg = The sheep name is not created.;catch(Exception e)m_strMsg = * some exception occured! (CMP) .concat(String.valueOf(String.valueOf(e.getMessage();此时测出来的数据，TPS平均值非常低，且测试时Response Time总是随着时间的增长几乎呈线性攀升。于是用Method Profiler进行诊断：（1） 在JRockit的启动参数中加入-Xmanagement，以便启动JRockit的时候同时启动其Management Server。（2） 启动JRockit Management Console，并且将其连接到启动了的Management Server上。（在做压力测试时用JRockit Management Console进行观察对性能的损耗可以忽略不计）（3） 在JRockit Management Console中，将ToolsPreferences菜单中的Mode of operation属性设为developer。（4） 在Method Profiler属性页中添加你所需要观察的类的成员方法。（5） 按Start按钮让Method Profiler开始进行统计。Time/Inv(ns)指标的显示结果表明Stateful4CMPBean.ejbCreate()代码所含逻辑成为了系统的瓶颈。结果又显示getNextId()和home.create()操作消耗的时间只占Stateful4CMPBean.ejbCreate()的一小部分，而sheep.setName()操作消耗的时间却占了Stateful4CMPBean.ejbCreate()的剩下的（指除去getNextId()和home.create()操作消耗的时间）绝大部分。于是又用Method Profiler作了一系列实验，结果如下：用1个用户做压力测试，sheep.setName()操作消耗的时间为X，getNextId()操作消耗的时间为Y，home.create()操作消耗的时间为Z；用2个用户做压力测试，sheep.setName()操作消耗的时间约为2X，getNextId()操作消耗的时间约为Y，home.create()操作消耗的时间约为Z；用3个用户做压力测试，sheep.setName()