weblogic调优

Server调优
　　WebLogic Server的核心组件由监听线程,套接字复用器和可执行线程的执行队列组成。当服务器由监听线程接收到连接请求后,将对它的连接控制权交给等待接收请求的套接字复用器。然后套接字复用器读取离开套接字的请求,并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。当有一个请求出现在执行队列中时，就会有一个空闲的执行线程从该队列中取走发来的该请求，并返回应答，然后等待下一次请求。因此要提高WebLogic的性能,就必须从调整核心组件性能出发。

1.尽量使用本地I/O库WebLogic Server有两套套接字复用器：Java版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNIX默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出 java.lang.UnsatisfiedLinkException,此时只能使用Java套接字复用器,可以调整socket readers 百分比,默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置。

2.调整默认执行线程数　　理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总线体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。 WebLogic生产环境下默认的线程为25个,随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多,线程数越小,CPU可能无法得到充分利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPUs为基准进行调整。当空闲线程较少,CPU利用率比较低时,可以适当增加线程数的大小(每五个递增)。对于PC Server 和Window 2000，则最好每个CPU小于50个线程, 以CPU利用率为90%左右为佳。由于目前WebLogic执行线程没有缩小线程数的功能,所以应将参数Threads Increase设置为0,同时不应改变优先级的大小

3.调整连接参数　　WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。这些参数可以在Console Server Tuning Configration配置栏里找到。

4.创建新的执行队列　　创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级,这里优先级不应设为9或者10。 定义一个新的执行队列很容易,利用View Excute Queue选项中的Configure a new Excute Queue链接即可定制新的执行队列。创建新的执行队列后，用户需要为应用程序的J2EE组件配置分配策略，以便它可以找到新的队列。举个例子：要将 servlet或jsp捆绑到一个特定的执行队列，必须替换web.xml文件项，将wl-dispatch-policy初始化参数设置为自己的执行队列名。

<servlet>
<servlet-name>servletname</servlet-name>
<jsp-file>/directoryname/deployment.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>NewExecuteQueueName</param-value>
</init-param>
</servlet>
　

我们可以为一个jsp或者servlet乃至一个WEB应用设置自己的执行队列。同时也可以为EJB设置自己的执行队列。对于执行时间比较长的MDB,建议使用自己的执行队列。

 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。

 WEB调优

调整WEB应用描述符

WEB应用除代码之外的调优比较简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session MonitoringEnabled,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间。同时生产环境下无需检查Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSPKeepGenerated和JSPVerbose对性能也有帮助。此外，还可以对jsp进行预编译,有两种方法：激活precompile选项；使用weblogic.appc事先编译，建议采用后者

JMS调优
1. 增加-Dweblogic.JMSThreadPoolSize=n(至少为5),以提高处理JMS的线程数,在jRockit上增加-XXenablefatspin以减少加锁冲突;
2. 采用文件存储策略,将同步写策略设置为Direct-Write,同时在windows平台上启用磁盘写入缓存;
3. 使用分布式目的地时,激活连接工厂LoadBalancing Enabled ,Server Affinity Enabled;
4. 为减少服务器不必要的JMS请求路由,如果多个目的地之间存在事务,则部署在同一JMS服务器上,尽量将连接工厂部署到JMS服务器所在的WebLogic实例上,集群环境下，则最好将连接工厂部署到集群中的所有服务器上,而集群中每个JMS服务器和目的地成员尽量使用类似的设置；
5. 启用消息分页存储功能,以释放内存,可以为JMS服务器和目的地设置,激活MessagesPaging Enabled和BytesPaging Enabled,同时使用限额防止服务器耗尽接收消息的所有可用内存空间;
6. 在运行WebLogicServer进程之外的生产者务必使用流控制,并增大Send Timeout;
7. 将JMSServer Expiration Scan Interval设很大的值，能禁止主动扫描过期消息;
8. 使用FIFO或者LIFO方式处理目的地消息;
9. MDB的max-beans-in-free-pool不应大于最大MDB线程数(默认线程数/2+1)。

Oracle性能优化

Oracle9i的性能优化除了调整kernal之外就是主要对Oracle启动文件的调整,即调整SGA的参数。注意,不同操作系统不同位数的机器最优的参数不是一样的,这里主要有windows和unix之分,32位和64位之分。
首先需要调大进程数和游标数,一般默认的值对实际应用来说都比较小,比如说,进程数可以调到300,游标数可以调到500。

　　其次,看一个经验公式:OS使用内存+ SGA + session*(sort_area_size +hash_area_size +2M)<0.7RAM,通常认为此时的SGA比较合理。这里sort_area_size为64k, hash_area_size为128k(当排序多的时候需要增大sort_area_size,按调整后的值计算),session表示最大并发进程数,假设100个。假如1G内存的机器,OS占用200M,PGA占用200M左右,那么SGA可以设为400-500M，如果2G内存可以1G给 SGA，8G可以5G给SGA。不过对于32位数据库来说，通常最多只能使用1.7G内存。

　　然后，SGA内参数设置的基本原则是： data buffer通常可以尽可能的大，shared_pool_size 要适度，log_buffer 通常大到几百K到1M就差不多。具体的：data buffer 1G内存可以设置500M，2G设为1.2G，8G可设为5G。shared_pool_size不易过大，通常应该控制在200M--300M,如果使用了大量的存储过程，可以根据SGA的值增大到500M，如果增大后命中率得不到提高，则增加是无益的。具体的：1G内存可以设置100M，2G设为150M，8G可设为300M。如不使用Java，java_pool_size 10-20M即可。large_pool_size如果不设置MTS，在20M-30M即可，假如设置 MTS,可以考虑为 session * (sort_area_size + 2M)。

　　最后，关于内存的设置可根据statspack信息和v$system_event,v$sysstat,v$sesstat,v$latch等view信息来考虑微调。

为了Oracle高效率的运行，除了上面提到的内存因素之外，还有就是需要良好的数据库设计：表、视图、索引和日志的合理规划和建立。I/O的性能也是重要因素，应尽量减少页交换和页分配。此外，就是改善检查点的效率。

操作系统调优

操作系统影响应用程序运行性能的因素主要有：硬件的配置(CPU、内存、硬盘等),核心参数,TCP/IP参数以及补丁的情况等。这里对操作系统的优化,除了更新最新的补丁程序以保证应用程序正常运行之外,就是调整TCP/IP参数,文件描述符,对于个别操作系统还有其他特别的参数调整

HP-UX
　　对于HP-UX,你首先需要安装Java Patch:
http://www.hp.com/products1/unix/java/patches/index.html,然后需要确认下面文档中的核心参数是否满足(可以使用sam命令修改核心参数):http://e-docs.bea.com/platform/suppconfigs/configs81/hpux11_risc/81sp3.html#80105。

　　调整TCP参数:ndd -set /dev/tcp tcp_conn_req_max 1024,将侦听队列的最大允许长度调整到1024。有时操作系统限制进程使用的最大内存数小于你要配置的内存大小,则需要调整该值。

　　读者可以从http://docs.hp.com/hpux/onlinedocs/TKP-90203/TKP-90203.html了解更多的HP-UX调整建议

Solaris
　　调整TCP的参数,等待时间间隔tcp-time-wait-interval建议设置为60000ms: /usr/sbin/ndd ?set /dev/tcptcp_time_wait_interval 60000;
其他参数调整如下:

tcp_xmit_hiwat/tcp_recv_hiwat 131072
tcp_conn_req_max_q/tcp_conn_req_max_q0 16384
　　调整一个进程打开的文件描述符的数量:软限制和硬限制以及散列表的大小,修改/etc/system文件:
set tcp:tcp_conn_hash_size=32768
set rlim_fd_cur=8192
set rlim_fd_max=8192
更多的调整信息请查阅: http://docs.sun.com/db/doc/806-7009(Solaris9)。

AIX
AIX用no命令调整TCP参数，等待时间间隔tcp_timewait: no -o tcp_timewait=4,将tcp.timewait参数设置为4个15秒间隔，即1分钟。运行no -a命令将显示网络当前的所有属性值。由于UDP_SENDSPACE默认的缓存大小是8k,为减少I/O异常,需调整为32k:
no -o udp_sendspace=32768。此外, 当WebLogicHTTP请求忙时,可以调整侦听队列的最大长somaxconn到8192(默认值是1024)。
　　更多信息:http://publib16.boulder.ibmo.com/pseries/en-us/aixbman/prftungd/prftungd.htm。

Linux
　　调整Linux系统使用sysctl命令修改TCP参数等待时间间隔:sysctl -wip_ct_tcp_timeout_time_wait=60;调整打开文件的最大数:在/etc/sysctl.conf文件中，添加: Fs.file-max=65535,然后运行sysctl -p;调整打开文件描述符最大数为8192:在/etc/security/limits.conf文件，添加:WebLogic hard nofile 8192(仅针对WebLogic用户),然后在WebLogic启动文件里运行ulimit-n8192激活设置。
更多信息请查阅:http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html。

Windows
Windows系统的调整通过修改注册表HKEY-LOCAL-MACHINESYSTEMCurrentControlSetServices文件夹来完成。可以调整TcpipParameters子文件夹中的等待时间间隔时间 TcpTimedWaitDelay参数的值。侦听队列最大长度的默认值为15，为修改它，可在InetinfoParameters子目录中创建 DWORD条目ListenBackLog。
此外,Windows2000的Service Pack(要求sp3以上)也会影响系统稳定性:http://e-docs.bea.com/platform/suppconfigs/configs81/win2ksvr_as_data_pentium/81sp3.html。

在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlset\Services\Tcpip\Parameters下加入新建值：

MaxUserPort，(DWORD值)十进制，65534

TcpTimedWaitDelay，(DWORD值)十进制，30

说明：同时使用这两个参数，集群时Windows服务器一定要设置。

·MaxUserPort：确定在应用程序从系统请求可用用户端口时，TCP/IP 可指定的最高端口号。缺省值：无。建议值：十进制 65534。

·TcpTimedWaitDelay：减少此条目的值允许 TCP/IP 更快地释放已关闭的连接，为新连接提供更多资源。如果运行的应用程序需要快速释放和创建新连接，而且由于 TIME_WAIT中存在很多连接，导致低吞吐量，则调整此参数。缺省值：240，它将等待时间设置为 240秒（4分钟）。 建议值：设置为30 秒。停止并重新启动系统。

性能监控和性能分析

性能瓶颈
　　介绍一下实际分析J2EE应用性能的常用命令和工具。对于实现一个高性能的J2EE应用来说,掌握了J2EE调优的理论经验还是不够的。掌握性能监控,发现瓶颈和问题诊断才是保证J2EE系统持续高效运行的关键。
瓶颈指的是限值所有吞吐操作以及严重影响反应时间的系统内资源。在分布式系统内寻找并纠正瓶颈是非常困难的，需要有经验的团队来解决。瓶颈会发生在Web服务器上，程序代码中，应用服务器上，数据库，操作系统或者网络，硬件上。经验表明，瓶颈很容易发生在如下地方：数据库连接与队列中；应用服务器的程序代码中；应用服务器和Web服务器硬件上；网络和TCP配置中。实际中可以着力对这些环节进行监控。

操作系统监控
　　操作系统层面的性能监控主要是对内存、CPU、I/O和交换区的使用情况进行监控分析。windows平台可以通过任务管理器和perfmon工具查看。如果是unix系统可以使用stat系列命令(vmstat,mpstat, iostat)监控内存、CPU和I/O的即时变化,使用swap命令查看交换区的使用情况。如果操作系统安装了top、topas、glance等使用工具,则使用top、topas、glance将能更为方便地看到WebLogic进程对操作系统的内存,CPU和I/O资源使用的即时变化情况。
　　而网络方面的性能可以通过ping和netstat等命令来监控,主要几个关键的网络统计值,如数据包再发送、重复数据包和数据包侦听丢失。
　　说明:本文提到的unix命令并非适用所有操作系统,仅供参考。

数据库监控
Spotlight等工具可以非常形象和直观地对Oracle数据库的CPU、内存、I/O、Data Buffer Size、Shared Pool Size、Redo Buffer等参数进行即时监控,并自动对不正常的参数以红色显示。

Console监控
WebLogicConsole除了管理配置功能之外,提供了丰富的监控功能。通过WebLogic Console，我们可以查看服务器的运行情况。

实用工具分析
WebLogic除了提供Console进行应用监控之外,用户还可以编写JMX程序或者通过SNMP协议进行监控。而QUEST Spotlight for WebLogic Server提供了类似WebLogic Console类似的监控功能,并对异常情况显红。
这里不得不提到实战中经常用来分析性能瓶颈的工具THREADDUMP,统一的命令是使用weblogic.Admin命令THREAD_DUMP。而在 windows上还可以使用<Ctrl>+<Break>来创建诊断问题所需的线程转储Thread Dump,而在unix上使用kill-3 <wlspid>命令。我们从中可以看到WebLogic后台线程的运行情况,通常需要每隔10秒左右持续执行几次以助诊断问题。更多信息可以参考BEA实战集锦。

应用程序分析
　　应用程序分析除了凭借程序员丰富的经验和敏锐的洞察力去人工检查代码之外,使用厂家的工具也是节省时间的不错选择。目前市场上有Borland OptimizeitEnterprise Suite和QUESTJprobe、jprofile可以用来分析性能瓶颈,垃圾收集,内存泄漏,线程死锁和代码复盖等。Hpjmeter是一个免费的工具,也具有以上类似的性能分析功能。