BEA WebLogic JRockit的使用和性能调优

一．JRockit调优简介

　　JRockit是一个自适应的JVM，它能够自动调整自己去适应底层硬件，因此对它的调优主要集中在一些需要人工干预的参数上，比如说：需要划分多少RAM给JRockit使用等。JRockit有一组非标准的-X启动选项，我们可以用它来调节JVM。JRockit有两组主要的子系统可以被优化--内存管理系统（包括垃圾回收）和线程系统。在内存管理子系统方面，有很多调优的工作可以做。 字串1

　　二．Tuning WebLogic JRockit JVM

　　1．设置初始堆尺寸

字串7

　　可以通过-Xms:m来设置初始堆大小，如果-Xmx的值小于128MB，则-Xms缺省取值为16MB；如果-Xmx设置大于128MB，则-Xms缺省值为物理内存的25%，最大不超过64M。例子： 字串3

　　-Xgc:gencon -xms:64m -Xmx:64m myClass 字串6

　　2．设置最大堆尺寸 字串4

　　可以通过-Xmx:m来设置最大堆尺寸。在IA32构架下，由于操作系统给每个进程的最大内存寻址空间为1.8G，因此最大堆尺寸不能超过1.8G。在IA64构架下，就没有1.8G的限制。 字串1

　　如果你的JAVA应用程序在运行时出现了Out of memory的错误，你就需要调大最大堆尺寸。如果没有设置最大堆尺寸，则缺省值为： 字串8

　　1． 如果设置了-Xgc:gencopy，由最大堆尺寸是min{400, 物理内存*75%}；

　　2． 如果没有设置-Xgc:gencopy，由最大堆尺寸是min{1536, 物理内存*75%}；

字串9

　　最好手工把最大堆尺寸设置为物理内存（1024M）的75%： 字串4

　　-Xgc:gencon -xms:64m -Xmx:768m myClass

字串3

　　3．设置Nursery的尺寸

字串6

　　可以使用-Xns:来设置Nursery的尺寸，我们要在保证垃圾回收停顿时间（garbage collection-pause）尽可能短的同时，尽量加大Nursery的尺寸，这在创建了大量的临时对象时尤其重要。缺省值为：

字串6

　　1． 对于-Xgc:gencopy，缺省的Nursery大小为320KB/CPU，对于10个CPU的系统来说，Nursery大小为3200KB（3.2M）

字串6

　　2． 对于-Xgc:gencon，缺省的Nursery大小为10M/CPU，对于10个CPU的系统来说，Nursery大小为100M 字串1

　　4．定义内存空间的清理时机 字串8

　　可以使用-Xcleartype:来定义已经被垃圾回收的内存空间在什么时候可以被清理，支持以下三种方式：

　　1． gc，在垃圾回收的同时清理内存； 字串3

　　2． local，在分配了一块thread-local区域时清理内存，仅在把参数-Xallocationtype设置成local时才有用；

　　3． alloc，在这块内存被分配给其它对象时清理。在IA64上目前还不支持。 字串4

　　缺省值为：

　　1． IA32上缺省值为alloc 字串7

　　2． IA64上缺省值为gc 字串7

　　5．定义线程分配的类型 字串4

　　可以使用-Xallocationtype:来定义线程分配的类型。

　　1． global，在最大堆尺寸比较小时（小于128M）或者应用程序大量使用了线程时使用。 字串5

　　2． local，在最大堆尺寸比较大时（大于128M）或者应用程序少量使用了线程时使用。

字串5

　　缺省值： 字串8

　　1． 如果设置了-Xgc:gencopy，缺省值为global 字串7

　　2． 如果设置了-Xgc:siglecon，-Xgc:gencon和-Xgc:parallel，缺省值为local 字串3

　　6．定义线程栈尺寸 字串1

　　可以使用-Xss[k|K][m|M]来定义线程栈大小。最小线程尺寸定义如下： 字串8

　　1． thin threads：最小线程栈尺寸为8K，缺省为64K；

字串8

　　2． native threads：最小线程栈尺寸为16K

　　如果-Xss设置小于最小值，则自动使用最小值。 字串1

　　缺省值： 字串7

　　1． IA32系统，WIN32：64K，LINUX32：128K

　　2． IA64系统，WIN64：320K，LINUX64：1M 字串8

　　二．Basic Tuning Tips and Techniques 字串4

　　尽管JRockit提供了一组缺省的OOTB配置选项，但最好根据实际应用情况来对JRockit作一些调整。

　　1．决定你要在哪方面调优

字串2

　　要考虑的因素有：

字串6

　　1． 要为JRockit分配多少内存空间； 字串5

　　2． 你要调优的目的是什么，是要得到更好的响应性还是更好的性能； 字串8

　　2．设置堆尺寸 字串6

　　对于堆尺寸来说，当然是越大越好了。如果设得不够大，就会造成Out-of-memory和内存分页错。如果同时运行了多个应用程序，建议把最小和最大堆尺寸设置成一样大。

字串2

　　3．在高响应性方面的调优 字串3

　　要得到更好的响应性能，应该设置 字串1

　　1． 使用并发垃圾回收器。-Xgc:gencon 字串4

　　2． 设置初始和最大堆大小。-Xms512m，-Xmx768m，由于使用了并发垃圾回收器，所以堆大小不会造成长时间的等待。

　　3． 设置nursery尺寸。如果用到了大量的临时对象，则需要适当的调大nursery尺寸。调大nursery尺寸会导致垃圾回收的停顿时间加长，因此要注意，确保垃圾回收的停顿时间在可忍受的范围内，这个停顿时间可以通过设置-Xgcpause来查看。

　　4．在高性能方面的调优 字串7

　　如果要得到更好的性能，你应该： 字串3

　　1． 选用并行垃圾回收器，由于并行垃圾回收器不使用nursery，因此你不必再设置-Xns，方法是加上-Xgc:parallel 字串4

　　2． 把初始和最大堆尺寸设置调到尽可能的大。方法是-Xms512m, -Xmx768m。

　　5．分析垃圾回收和停顿时间

字串2

　　1． 使用-Xgcreport生成报表，显示垃圾回收的统计信息，从中可以看出你是不是最有效地使用了垃圾回收器。 字串1

　　2． 使用-Xverbose:memory来显示在运行期间每一次垃圾回收的停顿时间。本选项仅用于调试，会产生大量的控制台输出。 字串3

　　6．调整线程选项

　　当大量地使用了线程时（超过100个），需要调整线程选项： 字串8

　　1． 使用thin线程选项。-Xthinthreads。瘦线程模式在LINUX下非常有效。注意：瘦线程在JRockit中只是一个试验选项，不推荐广泛使用；

字串4

　　2． 关闭本地分配线程的选项。-Xallocationtype:global。每个本地线程区都要消耗大约2K的内存，如果大量地使用了线程，本地线程不但会造成内存空间浪费，而且还会造成堆碎片。使用全局线程机制会减少堆碎片，但在内存分配方面速度要慢一些。

　　7．分析并改善应用程序设计 字串1

　　找出瓶颈方法： 字串4

　　1． 使用Intel VTune工具； 字串5

　　2． 使用-Xjvmpi:allocs=off,monitors=off,entryexit=off选项。

三．Command Line Options by Name

　　启动JRockit时，可以带一些-X选项，这些选项是非JVM标准的，专门用于配置JRockit的性能。

字串5

　　

选项 字串1	描述 字串2
-X 字串5	显示扩展Java选项 字串5
-Xallotype 字串3 　　-Xallocationtype 字串5	可取值global和local，定义使用本地线程还是全局线程。 字串7
-Xbootclasspath 字串1	指定类搜索路径，可以是ZIP和JAR文件，以；或：分隔 字串3
-Xcleartype 字串8	定义内存清理时机，可取值gc, local, alloc。gc表示在垃圾回收时清理内存；local表示时分配一块local线程区时清理；alloc表示内存区要被分配给其它对象时清理 字串3
-Xgc 字串4	选择要使用的垃圾回收器的类型，可取值： 字串7 　　gencopy：generational copying 字串3 　　singlecon：single spaced concurrent，单空间并发 字串4 　　gencon：generational concurrent 字串5 　　parallel：parallel 字串8 　　如果-Xmx小于128M，缺省使用gencopy，否则使用gencon 字串6
-Xgcpause 字串7	打印由垃圾回收器造成的停顿时间 字串4
-Xgcreport 字串8	打印垃圾回收报表 字串2
-Xjvmpi 字串7	是否允许JVMPI事件，这些事件有： 字串5 　　entryexit（缺省ON） 字串8 　　allocs（缺省ON） 字串3 　　monitors（缺省ON） 字串6 　　arenasdelete（缺省OFF） 字串5
-Xmanagement 字串4	激活JVM中的管理服务器，在JVM的管理控制台能连接到它之前，必须先激活。 字串6
-Xms 字串9	设置初始堆大小，单位有K、M、G 字串2
-Xmx 字串5	设置最大堆大小，单位有K、M、G 字串4
-Xnativethreads 字串7	使用本地线程系统，这是缺省选项 字串2
-Xnoclassgc 字串1	禁止对类作垃圾回收 字串8
-Xnohup 字串7	告诉JRockit，忽略CTRL_LOGOFF_EVENT和SIGHUP事件 字串6
-Xns 字串1	设置nursery尺寸，单位有K、M、G 字串6
-Xss 字串7	设置线程栈尺寸，单位有K、M、G 字串2
-Xthinthreads 字串4	使用JRockit的高性能线程系统，在IA64上不可用。 字串9
-Xverbose 字串8	让JRockit打印更多的信息，可选的参数有： 字串2 　　codegen、cpuinfo、gc、load、memory、Opt 字串3
-Xverify 字串9	作完整的bytecode一级的校验 字串4

　　四．用JRockit8.1中的Method Profiler调优WebLogic 字串5

　　1．关于Method Profiler工具 字串3

　　BEA WebLogic JRockit 8.1提供了一个Profiling工具：Method Profiler来调优WebLogic应用。 字串6

　　2．利用Method Profiler调优WebLogic应用 字串8

　　JRockit 8.1所带的Method Profiler工具能够将所有在JRockit Java虚拟机上执行的成员方法的调用次数、执行的总时间和每次调用的执行时间都统计出来，如图1所示。这样的功能一来可以让我们对跑在WebLogic上的应用进行tuning（代码级的），二来也大大方便了我们确定系统瓶颈在何处。这也可以说是JRockit JVM相对于其他JVM在功能上的一大优势。 字串2

　　在一次对WebLogic Server 8.1的压力测试中，对一组包含了CMP特性的样本进行压力测试时，就利用JRockit的Method Profiler诊断出了系统的瓶颈所在，现介绍如下。CMP这组样本中原先对CMP Entity Bean的操作除了用ejbCreate插入一条记录之外，紧跟着用setName方法设置其name属性，即UPDATE其对应数据库记录中name域的值，代码如下： 字串9

　　public void ejbCreate() //Stateful4CMPBean中的方法
throws CreateException
{
try
{
Context 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)));
} else
{
m_strMsg = "The sheep name is not created.";
}
}
catch(Exception e)
{
m_strMsg =
"*** some exception occured! (CMP) ".concat(String.valueOf(String.valueOf(e.getMessage())));
} 字串3
} 字串2

　　此时测出来的数据，TPS平均值非常低，且测试时Response Time总是随着时间的增长几乎呈线性攀升。于是用Method Profiler进行诊断：

字串5

　　（1） 在JRockit的启动参数中加入-Xmanagement，以便启动JRockit的时候同时启动其Management Server。

字串8

　　（2） 启动JRockit Management Console，并且将其连接到启动了的Management Server上。（在做压力测试时用JRockit Management Console进行观察对性能的损耗可以忽略不计） 字串6

　　（3） 在JRockit Management Console中，将ToolsàPreferences菜单中的Mode of operation属性设为developer。 字串7

　　（4） 在Method Profiler属性页中添加你所需要观察的类的成员方法。

　　（5） 按Start按钮让Method Profiler开始进行统计。 字串6

　　Time/Inv(ns)指标的显示结果表明Stateful4CMPBean.ejbCreate()代码所含逻辑成为了系统的瓶颈。结果又显示getNextId()和home.create()操作消耗的时间只占Stateful4CMPBean.ejbCreate()的一小部分，而sheep.setName()操作消耗的时间却占了Stateful4CMPBean.ejbCreate()的剩下的（指除去getNextId()和home.create()操作消耗的时间）绝大部分。 字串3

　　于是又用Method Profiler作了一系列实验，结果如下：用1个用户做压力测试，sheep.setName()操作消耗的时间为X，getNextId()操作消耗的时间为Y，home.create()操作消耗的时间为Z；用2个用户做压力测试，sheep.setName()操作消耗的时间约为2X，getNextId()操作消耗的时间约为Y，home.create()操作消耗的时间约为Z；用3个用户做压力测试，sheep.setName()操作消耗的时间约为3X，getNextId()操作消耗的时间约为Y，home.create()操作消耗的时间约为Z。可以比较肯定地判断，sheep.setName()执行的是一个串行化的逻辑。检查Oralce中UPDATE的ISOLATION-LEVEL，果然为SERIALIZABLE。

字串7

　　将sheep.setName("sheep1".concat(String.valueOf(String.valueOf(x)))); 这句代码删掉。 字串2

　　重新测试，TPS平均值有很大幅度的提高，Response Time在压力测试开始一段时间后也趋于平稳，几乎呈水平线走势。 字串7