java,weblogic和jdk性能文档(转)

1.应用服务器weblogic
应用服务器是weblogic8.1
1.1 weblogic核心运行规则
WebLogic Server的核心组件由监听线程,套接字复用器和可执行线程的执行队列组成。当服务器由监听线程接收到连接请求后,将对它的连接控制权交给等待接收请求 的套接字复用器。然后套接字复用器读取离开套接字的请求,并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。 当有一个请求出现在执行队列中时，就会有一个空闲的执行线程从该队列中取走发来的该请求，并返回应答，然后等待下一次请求.
(演示weblogic的监控页面)
1.1.1 演示线程监控
1.1.2 演示吞吐量,请求等待队列,内存使用和回收情况
1.2 weblogic的参数调整
调优并不是没有目标的调整.没有目标的调优是没有意义的.在一定的要求下才能有目标的调优.
A,调整默认执行线程数
理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总线体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。 WebLogic生产环境下默认的线程为25个,随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也 就越多,线程数越小,CPU可能无法得到充分利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPUs为基准进行调整(这是个 基准,实际可能跟这个有差距的)。当空闲线程较少,CPU利用率比较低时,可以适当增加线程数的大小(每五个递增)。对于PC Server 和Window 2000，则最好每个CPU小于50个线程, 以CPU利用率为90%左右为佳。由于目前WebLogic执行线程没有缩小线程数的功能,所以应将参数Threads Increase设置为0,同时不应改变优先级的大小。
在调整线程的过程中,如果cpu利用率已经达到90%以上,就不要增加线程数目了.没有意义了.调整线程和调整程序的性能是交互进行的.这个时候只能从代 码入手,降低程序对cpu的消耗和对数据库的访问,也就是降低单次访问的响应时间,然后可以重新增加线程的数量,提高并发性能.如果仍不能达到要求,就采 用集群,使用负载平衡器来增加并发的响应.
吞吐量是个不太重要的参数.反映了一个请求需要服务器方面返回的数据量.请注意,吞吐量不是瓶颈的反映.一个最简单的仅仅显示1000个汉字的jsp页 面,一次访问其吞吐量为2-3.数字平台的首页一次访问,吞吐量为60-80左右.除非减少页面上的内容,才可以使得单次访问的吞吐量下降.吞吐量从侧面 反映了服务器构造这个页面的负荷,侧面,也就是不一定能完全反映.
B, 调整连接前接受的请求数量参数.如果过小,会导致超过并发的请求直接被拒绝而不是等待.
WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。这些参数可以在Console Server Tuning Configration配置栏里找到。
C, 创建新的执行队列
创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级,这里 优先级不应设为9或者10。 定义一个新的执行队列很容易,利用View Excute Queue选项中的Configure a new Excute Queue链接即可定制新的执行队列。创建新的执行队列后，用户需要为应用程序的J2EE组件配置分配策略，以便它可以找到新的队列。举个例子：要将 servlet或jsp捆绑到一个特定的执行队列，必须替换web.xml文件项，将wl-dispatch-policy初始化参数设置为自己的执行队 列名。
D, JDBC性能调整
在WebLogic Server中，使用池缓冲到数据库的JDBC连接可以提高应用程序的性能。连接池根除了为每个应用程序创建新的数据库连接的需要。JDBC连接池提供到 您数据库的现成连接。使用连接池时，到数据库的连接的数目可以动态改变。但是，在负载高峰时期试图增加JDBC连接的数目将会使情况恶化，因为创建数据库 连接是一项开销昂贵的操作。连接池还可以通过缓存用于重用的prepared statement和callable statement来提高性能。重用prepared statement和callable statement可以降低数据库服务器上的CPU利用率。通过把其他应用程序分离到单独的机器或硬件上，可以避免耗尽WebLogic Server机器上的处理能力；为数据库指派一台专用的机器。
设置这个参数: mydomain> JDBC Connection Pools> MyPoolzxz1 (你的数据库连接池)
Statement Cache Size [300] 最大值允许为300
JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连 接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。一般我们设置这个数和线程的数据相等,保证每个线程都能用一 个现成的连接.
E, weblogic产品模式下表列出了开发模式与产品模式几种关键项的区别(这个对商店做参考)：
SSL
开发模式:你可以使用WebLogic安全服务提供的验证数字证书。有这些证书，你开发的应用程序会在SSL保护的环境下运行。
产品模式:如果你使用验证数字证书，会收到警告信息。
部署应用程序
开发模式:WEBLOGIC实例会自动部署和更新位于domain_name/applications目录下的应用程序（domain_name为域的名称）。
产品模式:不能使用自动部署功能，必须使用WebLogic控制台或者 WebLogiceblogic Deployer 工具。
Log File Rotation
开发模式:启动服务器后，服务器自动重命名本地日志文件为server-name.log.n，为了滞留的session ，只要日志文件的达到500kb，日志文件就会滚转一次。
产品模式:当日志文件达到500kb，就会滚转。
Execute Queues
开发模式:默认的执行线程为15
产品模式:默认的执行线程为25
JDBC Connection Pool Capacity
开发模式:默认的容量为15
产品模式: 默认的容量为25

F,群集 说明一个图即可,增加并发的一种方案.
2, 虚拟机
虚拟机是java程序运行的环境. 免费的虚拟机sun的jkd.最新的版本1.5 . bea公司也针对intel芯片开发了商用的虚拟机JRockit.IBM也有一款虚拟机.IBM JVM处理数学运算速度最快，而Sun JVM处理通常的商业逻辑性能最好,BEA JVM处理JRockit针对Intel 的CPU进行了指令优化JVM处理大量线程和网络socket性能最好.我们目前在linux下采用JRockit虚拟机.这个性能有一些提升,并在配置 方面非常简单.
关于Sun的JDK虚拟机.java虚拟机的启动和参数配置linux系统下在startWeblogic.sh中配置,window系统下在startWeblogic.cmd启动脚本文件中进行设置.
查看启动脚本文件.关注里面的两个启动变量JAVA_HOME和MEM_ARGS.前者设置虚拟机,后者设置的是虚拟机启动参数.如果不设置启动参数,启 动时将使用缺省的参数,缺省的参数根据不同的情况将使用不同的参数.默认的参数变量设置在D:\bea\weblogic81\common\bin \commEnv.cmd(linux下在/usr/local/bea/weblogic81/common/bin/commEnv.sh)文件中. 对于产品模式下,这些参数要根据实际的情况进行调整.下面给出不同的虚拟机下,参数的设置对我们数字平台的性能影响
1,sun的JDK 虚拟机性能调整
注意:以 -X 开头的选项都为非标准选项,谨慎使用。
1.1 简要说明: Java 堆 － 这是 JVM 用来分配 java 对象的内存。java 堆内存的最大值用 java 命令行中的 .Xmx 标志来指定。如果未指定最大的堆大小，那么该极限值由 JVM 根据诸如计算机中的物理内存量和该时刻的可用空闲内存量这类因素来决定。始终建议您指定最大的 java 堆值。堆大小的分配在weblogic的启动脚本中使用java命令加指定参数的方式分配内存.对于linux下的情况说明如下.默认的堆大小参数在 commEnv.sh脚本中根据不同的应用应用服务器和不同的操作系统进行了默认的参数设置.其中设置堆的环境变量为 MEM_ARGS.在生产环境中一般要对这个数据进行调整.
1.2 调整堆分配大小的方式: 在weblogic的启动脚本 startWeblogic.sh脚本中需要重新设置MEM_ARGS环境变量的值,他的值是字符串作为java虚拟机的启动参数.写法为(两个注意点 1,不要使用set ; 2,”=”后面要使用引号):
MEM_ARGS=” -Xmx512m -Xms512m -XX:NewSize=8m -XX:MaxNewSize=32m -XX:PermSize=128m -XX:MaxPermSize=128m”
echo ${MEM_ARGS}
参数详细说明:
-Xms512m 设置最小堆长,应设置为1024的倍数例如当前为:512m .根据你的服务器的内存大小来决定这个数据.设置为最大内存的80%.不要太大,否则会导致本地内存不足
-Xmx512m 设置最大堆长.同上的大小设置.最小堆长和最大堆长一样的设置可以避免内存回收后引起内存分配的调整.
-XX:NewSize=128m 设置新生成堆长.这个参数一般设置为10m左右.当增加了CPU的数量后,一定要增加这个参数值.因为其可能并行分配内存而不是回收内存。如果存在大量短 寿命对象，应增大此值.这个参数直接影响伊甸区小回收的回收幅度和频率.这个参数如果过小,则会导致小回收减缓,并尽量的使用空闲内存,导致大回收频繁; 这个数据过大(例如512M,和最大堆一半相当)将导致伊甸区内存垃圾达到小回收标准时间超长,舍得小回收频繁,大回收不明显,而且导致保持区变小,为了 保持对象存活使得大回收频率明显增加(几乎每2秒一次,一次大回收时间测试结果显示在1.5秒左右),严重影响系统性能.
-XX:MaxNewSize=128m 默认设置为NewSize的4倍.目前这个数据没有发现堆系统性能的明显影响.
-XX:PermSize=128m 持久区大小.持久区是虚拟机本身使用的区域.用来处理虚拟机自身的数据交换和对象保持.一般128m即可.
英文:One portion of the tenured generation called the permanent generation is special because it
holds all the reflective data of the virtual machine itself, such as class and method objects.
翻译:这个参数表示永久带大小.它是一个特殊内存,用来持有所有虚拟机本身的永久数据包括类和方法对象
-XX:MaxPermSize=128m 最大持久区大小.同上解释.

##上面的参数设置在下面的java虚拟机启动时会被引用为参数:
${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Dweblogic.Name=${SERVER_NAME} -Dweblogic.ProductionModeEnabled=${PRODUCTION_MODE} -Djava.security.policy=”${WL_HOME}/server/lib/weblogic.policy” weblogic.Server
1.3 参考: http://www.cybercorlin.net/forum/viewtopic.php?forum=5&showtopic=145
. 不要把服务器的堆大小设置得比机器上可用的自由RAM还大。否则会发生换页延迟,设置的过小,系统在分配内存时会报OutOfMemery异常,导致服务器崩溃.
· 为了获得高性能和高吞吐量，设置最小的JVM堆大小等于最大的堆大小。
· -verbosegc 选项,在生产运行期间避免使用,此参数将时虚拟机运行时打印垃圾回收情况.
· 在多CPU的机器上使用并行的垃圾收集算法，以减少垃圾收集的暂停时间。具体多种算法参考下面附录的虚拟机调整文档
· 要发现并删除锁定段，使用ipcs和 ipcrm
. -XX:+AggressiveHeap – 使用几乎和整个物理内存一般大的堆。
AggressiveHeap 警告：
1. 使用所有可用的内存。
2. 与 -Xms –Xmx不兼容。

. -XX:+UseISM – 使用隐私的共享内存 (Solaris)。
隐私的共享内存警告 (仅针对 Solaris):
1. 锁定内存；只在专门系统上使用。
2. 内存碎片能够防止分配连续的4 MB页面。
3. 异常的JVM终止能够导致出现锁定段。
4. 要发现并删除锁定段，使用ipcs 和 ipcrm(待详细解释)。
. -XX:NewSize=64m -XX:MaxNewSize=256m的作用跟Xmn是一样的，都是设置年轻代大小
1.4 垃圾回收算法
垃圾收集也可以清除内存记录碎片。由于创建对象和垃圾收集器释放丢弃对象所占的内存空间，内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存洞。碎 片整理将所占用的堆内存移到堆的一端，JVM将整理出的内存分配给新的对象。Java语言规范没有明确地说明JVM使用哪种垃圾回收算法，但是任何一种垃 圾收集算法一般要做2件基本的事情：（1）发现无用信息对象；（2）回收被无用对象占用的内存空间，使该空间可被程序再次使用。
1,throughput收集器.这个使用年轻带的并行版本.使用 -XX:+UseParallelGC 参数启动.启动后,保持”带”收集器就是默认的回收器.
2,并发低暂停回收器.这个回收器使用-XX:+UseConcMarkSweepGC参数启动.并发回收器通常收集保持带而且大多数收集工作和应用程序 并行处理.应用程序在收集期间只需短暂的暂停.使用参数 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 一个并行版本的年轻代收集器被复制被用来当作并发收集器.
3,增量低暂停回收器.这个回收器使用-Xincgc 参数启动.注意,这个增量垃圾回收器是当作最小回收的一部分,试图分散主回收的大暂停时间到许多小的小回收中.然而,如果考虑全部的吞吐量,它甚至比缺省 的保持回收器更浪费时间,只是它变得分散罢了,暂停时间变小了.
注意-XX:+UseParallelGC 和-XX:+UseConcMarkSweepGC不应该一起使用.1.4.2版本的J2SE平台仅仅允许合法的参数组合出现.但早期发布的可能检测不出非法的组合.结果非法的组合导致的结果不可预知.
一般,首先使用缺省的收集器.调整堆大小来迎合你的应用即可,如果实在不行,怎么也不能满足要求,然后在考虑使用其他的收集器.
1.5 经验数值:
JVM 的堆大小决定了 VM 花费在收集垃圾上的时间和频度(最重要的性能影响)。
如果系统花费很多的时间收集垃圾(也就是一次回收需要花费的cpu时间),请减小堆大小
一次完全的垃圾收集应该不超过 3-5 秒
一般说来，你应该使用物理内存的 80% 作为堆大小
每次垃圾收集后堆的效果如何。如果堆在回收后通常是85％左右，则应增加堆大小。
如果发现垃圾收集的时间太长，则应考虑减小堆大小。典型情况是应该分配给JVM80％的内存资源。

2 .JRockit虚拟机
在基于Intel的体系结构上，为了获得更好的性能，把WebLogic配置为使用JRockit虚拟机。 bea公司开发的这个虚拟机是为了使用最简单的配置来达到最好的运行效果.所以这个虚拟机比sun的JDK虚拟机更加简单. 如果运行的是具有超线程功能的Intel处理器，在安装完成后需要一个额外的步骤。任何一个处理器（实际的或虚拟的）的cupid必须可被任意进程读取； 此功能既可自动实现也可通过修改/dev/cpu/X/cupid（X是CPU号）文件的权限来实现。有关启用此功能的技术细节，请参考JRockit 的发布说明（http://edocs.bea.com/wljrockit/docs81/relnotes/relnotes.html ）
JRockit的安装配置文档,请参考<<使用Jrockit.doc>>文档.
使用文档中介绍的配置.如果涉及到垃圾回收暂停时间问题,则考虑其他垃圾回收算法. 你要调优的目的是什么，是要得到更好的响应性还是更好的性能.
下面为虚拟机启动选项:
MEM_ARGS=”-Xns:8m -Xmx:1024m -Xms:1024m JAVA_VM=” -server -Xmanagement -Djrockit.managementserver.port=7093″
注意几点:

缺省使用gencopy，否则使用gencon
>: 使用-Xns:<size>来设置Nursery的尺寸，我们要在保证垃圾回收停顿时间（garbage collection-pause）尽可能短的同时，尽量加大Nursery的尺寸，这在创建了大量的临时对象时尤其重要。缺省值为：
对于-Xgc:gencopy，缺省的Nursery大小为320KB/CPU，对于10个CPU的系统来说，Nursery大小为3200KB（3.2M）
对于-Xgc:gencon，缺省的Nursery大小为10M/CPU，对于10个CPU的系统来说，Nursery大小为100M

>: -Xmx:1024m -Xms:1024m 推荐这个两个数据设置为一样大小.
>: -Xgc:gencon 如果要得到最快的响应性能,就可以不设置任何回收算法,缺省的就是这个算法.低暂停回收,你可以设置最大的可用内存.
如果你的系统有大量的临时对象,则需要设置新生堆(例如: -Xns:8m)
>: -Xgc:parallel 为了得到更好的性能,选用并行垃圾回收器，由于并行垃圾回收器不使用nursery，因此你不必再设置-Xns;
更加详细的中文翻译说明,请参考:http://dev2dev.bea.com.cn/techdoc/jrockit/20031199.html
更详细的JRockit英文官方说明,请参考:http://e-docs.bea.com/wljrockit/docs81/userguide/mancons.html
更详细的JRockit官方调优说明,请参考:http://e-docs.bea.com/wljrockit/docs81/tuning/index.html

3, 工具
Jrockit使用
JRockit监控.
两种监控方式:
第一种是使用weblogic控制台远程监控.打开weblogic控制台
->servers ->myserver->monitoring -> JRockit 这里显示了 内存,垃圾回收,cpu占有率方面的信息等其他信息.这个监控仅仅监控远程的运行状态,不比下面本地的监控还能监控类方法的执行时间.如果要查找瓶颈,只 能使用下面的第二种方法.
第二种方法是,使用本地的JRockit配置监控远程的服务器.如果本地安装过weblogic的8.1版本.则找到weblogic的安装目录下的 C:\bea\jrockit81sp3_142_04\console\ManagementConsole.jar 用javaw.exe打开这个jar .注意虚拟机启动一定要使用-Xmanagement -Djrockit.managementserver.port=7093参数. 其中的端口可以自己设定(缺省是7090).启动后,出现监控的界面.需要配置如下:
建立一个new connection
输入一个名称,输入远程的地址,输入监控端口(和上面的一致7093,缺省是7090)
点击绿色的connect,当前的配置管理节点的红色的圆球变为绿色了.表明开始监控.
上面的几个页面中
Overview 概要观察页面
Memory 内存观察页面
Processor Cpu观察页面
System 系统页面
Notification 警告提示设置页面
Method Profiler 方法观察工具
Exception Count 异常观察
重点说明Method Profiler页面的方法执行时间用来查找瓶颈的用途.
点击new template新建一个模板,这个模板就是方案.点击下面的Add method 按钮.输入类的名称,点击 next ,显示了此类内的所有方法,选择你要的方法,多选即可.单击finish,这个方法被添加到方法列表中去了.点击上面的 star 按钮,方法都进入准备状态,访问主页一次,后台的方法被调用,这里也显示方法的调用次数和耗用的时间.上面的几个列,列出的就是 方法名称,调用次数,共计耗时(ms),单次平均时间(ns).
根据上面的数据.优化程序,提高效率.
loadRunner使用
loadRunner是测试并发的工具.
loadRunner分为两个部分,一个是录制脚本的程序.一个执行脚本进行测试的部分.
并发测试有两个参数可以设置: 1,并发的数量 2,每个并发连续运行的次数
运行完毕后,从图表中可以查看单次请求的响应时间.请注意并发并不是盲目设置的,并发的数目要以weblogic的线程多少为基准.对于高并发的测试,如 果测试的响应时间和要求的响应时间相差遥远,请耐心细致的进行程序调优,然后在进行测试.并逐渐的调高weblogic线程数和测试的并发数.是一个反复 的过程.
JProbe使用
JProbe提供了更宽阔的空间.不局限于weblogic服务器.可以设置任何服务器.　Probe Suite 是Java最佳的性能调优组件工具包，提供了高级的、高灵活性的Java应用程序调优，而不管其在本地运行还是在远程运行。
组件包中包括：
JProbe Profiler(诊断Java代码中性能瓶颈)、
JProbe Memory Debugger(发现Java代码中的内存泄漏)、
JProbe Threadalyzer(多线程分析)
JProbe Coverage(代码覆盖分析).