weblogic性能调优

注：在下面做的介绍都是以Weblogic8.1为例的，其它版本的Weblogic可能会有些许不同。

1) 设置JAVA参数；
a) 编辑Weblogic Server启动脚本文件；
BEA_HOME\user_projects\domains\domain-name\startWebLogic.cmd(startWebLogic.sh on Unix) 
BEA_HOME\user_projects\domains\domain-name\startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix) --这个是做集群的时候用的
b) 编辑set JAVA_OPTIONS命令，如：set JAVA_OPTIONS=-Xms256m –Xmx256m；
（在UNIX下把MEM_ARGS="-Xms1024m -Xmx1024m -Xmn128m"加到上述两个.sh文件中即可）
c) 保存，重启即可。
注：在WebLogic中，为了获得更好的性能，BEA公司推荐最小Java堆等于最大Java堆。
（这个偶们的设置都是1024M的，反正偶们内存大大的4G呢）

2) 开发模式 vs. 产品模式；
开发模式和产品模式的一些参数的默认值不同，可能会对性能造成影响，下面是对性能有影响的参数列表：

参数	开发模式默认值	产品模式默认值
Execute Queue: Thread Count	15 threads	25 threads
JDBC Connection Pool: MaxCapacity	15 connnections	25 connections

通过启动管理控制台，在域（如：mydomain）> 配置 > 常规选择产品模式。
（这个在创建weblogic的domain的时候是有选择的，选择“产品”模式就可以了，如果后期需要修改，可以按照上面的方法修改）

3) 尽量开启本地I/O；
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 配置 > 调整选择启用本地I/O。
注：此值也可通过手动的修改config.xml配置文件。
（这个没有试验过，不晓得有什么效果和好处，知道的告诉偶下下。）

4) 调优执行队列线程；
a) 修改默认执行线程数
在这里，执行队列的线程数表示执行队列能够同时执行的操作的数量。但此值不是设的越大越好，应该恰到好处的去设置它，太小了，执行队列中将会积累很多待处理的任务，太大了，则会消耗大量的系统资源从而影响整体的性能。在产品模式下默认为25个执行线程。
（点：一般来说，其上限是每个CPU对应50个线程，其按照CPU个数线性增长.）

为了设置理想的执行队列的线程数，我们可以启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 监视 > 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数，据此确定理想的数值。
理想的默认执行线程数是由多方面的因素决定的，比如机器CPU性能、总体体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。随着CPU个数的增加，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。在测试中，可以以25*CPU个数为基准进行调整。当空闲线程较少，CPU利用率较低时，可以适当增加线程数的大小（每五个递增）。对于PC Server和Windows 2000，则最好每个CPU小于50个线程，以CPU利用率为90%左右为最佳。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置中修改线程计数。

b) 设定执行队列的溢出条件；
    Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。
    通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置下面几项：
●队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。
●队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。
●线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和内存不是足够的高，尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。
●最大线程数：为了防止创建过多的线程数量，可以通过设定最大的线程数进行控制。
在实际的应用场景中，应根据具体情况适当的调整以上参数。

c) 设定执行队列监测行为
Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态，可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities文档。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置下面几项：
●阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。
●阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了 "阻塞线程最长时间" 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为 600 秒。

5) 调优TCP连接缓存数；
WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。
Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置“接受预备连接”。

6) 改变Java编译器；
标准的Java编译器是javac，但编译JSP servlets速度太慢，为了提高编译速度，可以使用sj或jikes编译器取代javac编译器。下面说说更改Java编译器：
通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 常规下改变Java 编译器，默认为javac。输入完整路径，如：c:\visualcafe31\bin\sj.exe。然后打开高级选项，在预规划到类路径填写编译 Java 代码时为 Java 编译器类路径预规划的选项，如：BEA_HOME\jdk141_02\jre\lib\rt.jar。

7) 使用Webogic Server集群提高性能；
具体关于如何配置Weblogic集群，我就不细说了。详情可参考：Introduction to WebLogic Server Clustering。

8) Weblogic EJB调优
由于EJB2.0已经很少项目在用了，EJB3.0再成熟一点，我再补充这一部分吧！

9) JDBC应用调优
JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。
增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。
尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。
最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。

10) JSP调优
设置jsp-param pageCheckSeconds=-1；
设置serlet-reload-check=-1或ServletReloadCheckSecs=-1；
设置jsp-param precompile=true，关闭JSP预编译选项。

Tags: weblogic, java, 性能调优

 

一个牛人给出的参考：
系统的线程池配置考虑以下因素：
1，  机器的计算能力；
2，  子系统每个线程的计算复杂性；
3，  整个系统的均衡性。

因此，建议设定一个标准范围，例如（举例说明，具体数值根据情况斟酌）：
机型：DL380G4/2*3G/4G，线程池大小范围：80－120（无特殊情况一般设为100）；
机型：DL380G5/2*2G/4G，线程池大小范围：100－120（无特殊情况一般设为110）；
机型：BL460C/2*3G/4G，线程池大小范围：100－120（无特殊情况一般设为110）；

Post by iceskysl on 2007, September 18, 11:50 AM  #1

系统文件描述符数目不足
Log中有“too many open files”的错误
表示达到了系统对一个进程能同时打开的文件数的限制
ulimit –a –H 可以查看当前限制
ulimit –n number可以来更改当前环境的设置，建议至少设到4096
Solaris上可以通过/usr/proc/bin/pfiles pid来查看指定进程的限制和当前使用的file descriptor数目
Solaris上root用户可以通过/usr/proc/bin/plimit -n soft,hard pid 来动态更改进程的文件描述符的限制
Post by iceskysl on 2007, September 18, 11:55 AM  #2

系统内存不足
JVM的heap区大小
通过java命令行中的-Xms,-Xmx指定，建议最小值和最大值设成一样
可以通过weblogic console上server/monitor/performance来观察其使用情况
建议生产系统最少256M，一般情况下可以设置为系统剩余物理内存的80％
Post by iceskysl on 2007, September 18, 11:57 AM  #3

failureException: Error initializing Embedded LDAP Server - with nested exception: [java.lang.ClassCastException] java.lang.ClassCastException at weblogic.ldap.EmbeddedLDAP.initialize(EmbeddedLDAP.java:266)

改权限chown -R weblogic.weblogic /home/webogic
Post by iceskysl on 2007, September 18, 4:37 PM  #4

修改文件句柄数：
1、修改/etc/security/limits.conf，需要root权限
vi /etc/security/limits.conf
# 确认包含下面的内容：
*                soft    nofile          8192
*                hard    nofile          8192
修改后，su到目标用户，用ulimit –Hn和ulimit –Sn确认修改已生效

2、修改startManagedWebLogic.sh，找到resetFD那行，注释掉。然后在脚本最后启动JAVA进程的前面加上下面的内容，检查系统文件句柄数是否修改：
echo
echo "-----------------------------------------------"
echo "Begin to check the file descriptor limit"
fd=`ulimit -n`
if [ $fd -lt 8192 ];
   then
   echo "Fatal Error!"
   echo "The file descriptor limit is only '"$fd"'!"
   echo "Please make it more than 8192!"
   exit
fi
echo "OK, the file descriptor limit is" $fd
echo "-----------------------------------------------"
echo
echo
Post by iceskysl on 2007, September 18, 5:26 PM  #5

查看文件句柄数：
/usr/sbin/lsof -n|awk '{print $2}'|sort|uniq -c |sort -nr|more
Post by iceskysl on 2007, September 20, 10:53 AM  #6

我遇到的weblogic运行600秒超时主要有两个原因：
1）SQL语句运行时线程阻塞
2）out.println语句运行时线程阻塞

第一种问题的解决办法，编写一个java桌面应用，测试运行的SQL语句是否可以正常运行，并返还正确结果。若无法正常运行，就需要通过视图或其他的方式调整和优化SQL语句。
这里需要注意：数据库的不同版本可能需要相应版本的数据库驱动。SQL语句不能正常运行，通常都是由驱动引起的。

第二种情况的解决办法，weblogic或其他的中间件产品，服务端大多都会使用缓冲发送数据机制，当数据量大的时候会分批发送出去，若数据中出现过多的回车（\n或直接的回车）就会有一定的几率出线线程阻塞的情况，解决办法就是消除回车符，尽量使输出的数据是连续的字符流。
Post by iceskysl on 2007, September 22, 9:39 PM  #7

分析线程堆栈：
http://bbs.sinoweb.com.cn/archiver/tid-405.html
Post by iceskysl on 2007, September 23, 2:13 AM  #8

http://www.cntesting.com/portal/html/testing-technique/load-test/20070509/178.html
Post by iceskysl on 2007, September 23, 2:25 AM  #9

最近生产环境下的系统经常出现以下的错误提示，
####<2007-7-2 下午04时07分20秒 CST> <Error> <WebLogicServer> <gis> <portalServer> <weblogic.health.CoreHealthMonitor> <<WLS Kernel>> <> <BEA-000337> <ExecuteThread: '5' for queue: 'default' has been busy for "1,165" seconds working on the request "Http Request: /tzzmWeb/saye/regie/census/customertoMtn/custcheckout.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>

该问题是由于处理custcheckout.do请求超时引起的，系统配置的处理时间是600s，但是该线程处理了1165s后，仍然没将请求释放，所以报了这个错误。如果发送该请求较多，很有可能会导致weblogic的线程阻塞，严重会引起weblogic挂起现象。
可以通过以下几种方法解决：
1）修改StuckThreadMaxTime参数，将默认的600s改成1200s，或者其它适合的值。
2）增大线程数，防止线程阻塞问题。
3）优化程序，减少处理时间。

点评：还可能是网络的问题导致的～
Post by iceskysl on 2007, September 23, 12:12 PM  #10

JVM内存的设置的原理
http://hi.baidu.com/haoyan665/blog/item/e148c45001115f6084352422.html