weblogic优化设置&调优参数及监控指标

优化设置

Weblogic服务程序设置：

1、设置JDK内存：

修改weblogic\user_projects\domains\base_domain\bin下的setDomainEnv.cmd文件：修改前：

if "%JAVA_VENDOR%"=="Sun" (

set WLS_MEM_ARGS_64BIT=-Xms256m -Xmx512m

set WLS_MEM_ARGS_32BIT=-Xms256m -Xmx512m

) else (

set WLS_MEM_ARGS_64BIT=-Xms512m -Xmx512m

set WLS_MEM_ARGS_32BIT=-Xms512m -Xmx512m

)

set MEM_PERM_SIZE_32BIT=-XX:PermSize=48m

set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=128m

修改后：

if "%JAVA_VENDOR%"=="Sun" (

set WLS_MEM_ARGS_64BIT=-Xms512m –Xmx1024m

set WLS_MEM_ARGS_32BIT=-Xms512m –Xmx1024m

) else (

set WLS_MEM_ARGS_64BIT=-Xms1024m –Xmx1024m

set WLS_MEM_ARGS_32BIT=-Xms1024m –Xmx1024m

)

set MEM_PERM_SIZE_32BIT=-XX:PermSize=128m

set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=256m

说明：红色字体为修改的内容，具体修改值根据实际物理内存确定

?-Xmx3550m：设置JVM最大堆内存为3550M。

?-Xms3550m：设置JVM初始堆内存为3550M。此值可以设置与-Xmx相同，以避免每次JVM动态分配内存所浪费的时间。

?-XX:PermSize=256M：设置堆内存持久代初始值为256M。(貌似是Eclipse等IDE的初始化参数)

?-XX:MaxPermSize=512M：设置持久代最大值为512M。

32位操作JDK内存系统：最大可设置1.5G，如果设置过大，会导致服务无法启动

64位操作JDK内存系统：最大设置为物理内存的60~80%

2、设置线程数：

修改weblogic\user_projects\domains\base_domain\bin下的setDomainEnv.cmd中在JAVA_OPTIONS中添加如下：

set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.threadpool.MinPoolSize=2000

set JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.threadpool.MaxPoolSize=4000

说明：

JDK5.0以后每个线程栈大小为1M，但是操作系统对一个进程内的线程数还是有限制的，不能无限生成。32位操作系统根据JVM最大堆内存设置；64位操作系统经验值在3000~5000左右。

3、Weblogic数据库连接池连接数设置：

受Oracle数据库连接数的影响，可以参照同一时间连接数据库的用户数量，进行设置，数据库的最大连接数不能小于高峰时期同一时间连接用户的数量。点击数据源，进入后选择连接池：

初始容量：20

最大容量：50

容量增长：5

说明：

设置前得设置数据库的最大并发线程数（下面有介绍Oracle数据库线程数设置方法），因为weblogic节点的连接池最大连接数之和不能大于数据库的最大线程数。

?初始容量：要在创建连接池时创建的物理连接数。如果无法创建这一数量的连接，创建此连接池的操作将会失败。此连接数也是连接池将保持的最小可用物理连接数。

?最大容量：此连接池可容纳的最大物理连接数。

?容量增长：将新连接添加到连接池时创建的连接数。不再有可用的物理连接来满足连接请求时，WebLogic Server 会创建该数量的附加物理连接并将它们添加到连

接池中。MBean 属性(不适用于应用程序模块)：

JDBCConnectionPoolParamsBean.CapacityIncrement。

4、Weblogic的服务设置[配置\优化]：

接受积压：300

登录超时：5000

说明：

?接受积压：对于此服务器的常规和SSL 端口，应该允许的新TCP 连接请求的积压数量。将积压设置为0 可以防止此服务器接受某些操作系统上的所有传入连接。

MBean 属性：ServerMBean.AcceptBacklog。最小值：0

?登录超时：此服务器的默认常规(非SSL) 监听端口的登录超时。这是允许建立新连接的最长时间。如果值为0，表示无最大值。MBean 属性：

ServerMBean.LoginTimeoutMillis最小值：0。最大值：100000。安全值：5000

weblogic调优参数

对Weblogic的调优主要从SEVER、ExecuteQueue、JDBC等几个方面的相关参数进行调优：

一、SERVER

在mydomain->Servers->myserver->Configuration->Tuning->“Enable Native IO”中：

1、Native IOEnabled

TRUE，表示该Server使用本地I/O

2、SocketReaders

设置在执行线程中专用做Socket Readers的百分比

3、Maximum Open Sockets

最大打开Socket数

4、Stuck Thread MaxTime

堵塞线程时间，超过这个时间没有返回的执行线程，系统将认为是堵塞线程

如果weblogic认为某个队列中的所有的线程全部堵塞的话，weblogic将会增加执行线程的数量。

注意：执行线程的数量一旦增加，目前weblogic不会去减少他，如果增加了一些线程以后再

次出现overflow的警告，weblogic会继续增加执行线程的数量，一直到达到上限为止。

5、Stuck Thread Timer Interval

系统检查堵塞线程的时间间隔

6、Low Memory GC Threshold

当可用内存小于该百分比时，垃圾回收启动

7、Low Memory Granularity Level

当两次检测的可用内存变化超过该百分比时，垃圾回收启动

8、Low Memory Sample Size

在一次检测中的取样次数

9、Low Memory Time Interval

检测间隔时间

10、Accept Backlog

等待队列中最多可以有多少TCP连接等待处理，如果在许多客户端连接被拒绝，而在服务器端没有错误显示，说明该值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

二、ExecuteQueue

在mydomain->Servers->myserver ->Monitoring->Monitor all Active Queues... ->Configuration->weblogic.kernel.Default->

1、ThreadCount

服务器初始创建的执行线程的数量，设置原则：

增大机器的最大并发线程数使处理器利用率达到最大。对于服务器端操作比较多的线程，应该减少线程计数；对于客户端操作比较多的，应该增加线程计数。并发线程数理论上等于“本地主机CPU个数+Stuck线程数”，够用即可，过大会降低系统性能

2、QueueLength

在等待队列里的请求数，理想状态下是0

3、QueueLength Threshold Percent

一个百分数，当request的数量达到队列长度的这个比例的时候，weblogic会发出overflow的标志信息

4、ThreadsIncrease

如果weblogic发出overflow的标志信息，weblogic会尝试增加这个数量的执行线程，以解决处理矛盾

5、ThreadsMaximum

最大执行线程数

6、Threads Minimum

最小执行线程数

7、ThreadPriority

线程优先级

三、JDBC

在service->JDBC-> JDBC Connection Pools->Configuration->name->Connections

1、 Initial Capacity

初始数据库物理连接数

2、MaxCapacity

最大数据库物理连接数

3、Capacity Increment

每次数据库物理连接增加数

4、Statement Cache Type

prepared statements缓存的策略，LRU算法在有新的语句到来时，将最不经常被用得语句调整出缓存。FIXED算法为先进先出的算法

5、TestConnectionsOnReserve

TestConnectionsOnReserve设置为false（缺省设置）。如果此参数设置为真（true），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接

6、Statement Cache Size

宏语句设定的静态缓存，大小由JDBC连接池配置时指定，调整这个数值的大小，有利于提高系统的效率

7、Login Delay

创建数据库物理连接时的延时时间

weblogic监控指标

线程监控：

DOMAIN ->选择服务 -> Monitoring -> General -> Monitor all Active Queues... -> Monitor all Execute Threads...

在这个列表中可以看到应用当前处理的线程情况，若想进一步跟踪线程，可在使用KILL -3来跟踪查看进程情况，一般情况下线程存在如下状态：

A、Runnable：该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行

B、Wait on condition：该状态出现在线程等待某个条件的发生

1、线程在等待网络的读写

2、线程在 sleep，等待 sleep的时间到了时候，将被唤醒。

C、Waiting for monitor entry 和in Object.wait()：每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是“Active Thread”，而其它线程都是“Waiting Thread”，分别在两个队列“ Entry Set”和“Wait Set”里面等候。在“Entry Set”中等待的线程状态是“Waiting for monitor entry”，而在“Wait Set”中等待的线程状态是“in

Object.wait()”。线程为什么会进入“Wait Set”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入“Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ，“ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态

D、死锁：在多线程程序的编写中，如果不适当的运用同步机制，则有可能造成程序的死锁，经常表现为程序的停顿，或者不再响应用户的请求。

E、热锁：也往往是导致系统性能瓶颈的主要因素。其表现特征为，由于多个线程对临界区，或者锁的竞争，可能出现：频繁的线程的上下文切换：从操作系统对线程的调度来看，当线程在等待资源而阻塞的时候，操作系统会将之切换出来，放到等待的队列，当线程获得资源之后，调度算法会将这个线程切换进去，放到执行队列中。大量的系统调用：因为线程的上下文切换，以及热锁的竞争，或者临界区的频繁的进出，都可能导致大量的系统调用。大部分 CPU开销用在“系统态”：线程上下文切换，和系统调用，都会导致 CPU在“系统态”运行，换而言之，虽然系统很忙碌，但是 CPU用在“用户态”的比例较小，应用程序得不到充分的 CPU资源。随着 CPU数目的增多，系统的性能反而下降。因为 CPU数目多，同时运行的线程就越多，可能就会造成更频繁的线程上下文切换和系统态的 CPU开销，从而导致更糟糕的性能

连接监控：

DOMAIN ->选择服务 -> Monitoring -> General -> Monitor all Connections...

性能监控：

DOMAIN ->选择服务 -> Monitoring -> Performance

1、Idle Threads：已分配到队列的空闲线程数

2、Oldest Pending Request：被放置在队列中最常的请求所发生的时间

3、Throughput：The number of requests that have been processed by the queue

4、Queue Length:正在等待的队列

5、Memory Usage：当前内存堆栈使用情况

6、GC情况

消息监控：

DOMAIN ->选择服务 -> Monitoring -> JMS

1、Current Connections:

The current number of connections to this server.

2、Connections High:

The highest number of connections to this server since the last reset.

3、Total Connections:

The total number of connections made to this server since the last reset.

4、Current JMS Servers:

The current number of JMS servers that are deployed on this WebLogic Server instance.

5、Servers High:

The highest number of JMS servers that were deployed on this WebLogic Server instance since this server was started.

6、Servers Total: 0

The total number of JMS servers that were deployed on this WebLogic Server instance since this server was started.

事务监控：

DOMAIN ->选择服务 -> Monitoring -> JTA

1、Total Transactions: 1641

服务处理的事务总数

2、Total Committed: 1641

提交事务的总数.

3、Total Rolled Back: 0

回滚事务总数

4、Timeout Rollbacks: 0

由于超时异常回滚的事务数

5、Resource Rollbacks: 0

由于资源错误回滚的事务数

6、Application Rollbacks: 0

由应用回滚的事务数

7、System Rollbacks: 0

由系统回滚的事务数

8、Total Heuristics: 0

The total number of transactions that completed with a heuristic status.

9、Total Transactions Abandoned: 0

The total number of transactions that this server abandoned.

10、Active Transaction Count: 0

The number of active transactions on the server.

11、Average Commit Time: 0 ms

The average amount of time (in milliseconds) that transactions coordinated by this server have taken to commit.

请求监控：

DOMAIN -> Deployments -> Web Application Modules ->选择应用-> Monitoring->Servlets

列表中显示了服务启动以来请求的耗时情况

需要监控的日志：

1、server log

2、access log