一次weblogic调优的经过(StuckThreadMaxTime) of "600" seconds) .

一次weblogic调优的经过

项目组反应数据库有问题，

检查发现sga还用的默认参数，缓冲区命中率很低。根据系统内存调整后，好像系统正常了。数据库调整就算是结束了

一天后，我再登这个数据库的时候，发现一个提示说线程已经超过限制，不允许再登录。然后我去修改了process到250，增加并发连接数。然后重启了数据库。当天没发生什么事情，第二天，发现250又被撑满了，这个时候，我就开始换衣中间件有问题，登入中间件那边看了下日志，一直报错，提示无法打开新的连接。一般来说，中间件连接数据库能开10个都算可以了。至少websphere是这样，weblogic应该差不多。然后修改了一下，调整了weblogic的连接池，修改最大连接到100.

1、 报错信息

<2008-4-22 上午04时33分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT

hread: '1' for queue: 'weblogic.kernel.Default' has been busy for "102" seconds

working on the request "Http Request: /guestAction.jsp", which is more than the

configured time (StuckThreadMaxTime) of "60" seconds.>

<2008-4-22 上午04时33分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT

hread: '7' for queue: 'weblogic.kernel.Default' has been busy for "178" seconds

working on the request "Http Request: /guestAction.jsp", which is more than the

configured time (StuckThreadMaxTime) of "60" seconds.>

<2008-4-22 上午04时34分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT

hread: '0' for queue: 'weblogic.kernel.Default' has been busy for "111" seconds

working on the request "Http Request: /guestAction.jsp", which is more than the

configured time (StuckThreadMaxTime) of "60" seconds.>

<2008-4-22 上午04时34分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT

hread: '1' for queue: 'weblogic.kernel.Default' has been busy for "162" seconds

working on the request "Http Request: /guestAction.jsp", which is more than the

configured time (StuckThreadMaxTime) of "60" seconds.>

<2008-4-22 上午04时35分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT

hread: '0' for queue: 'weblogic.kernel.Default' has been busy for "171" seconds

working on the request "Http Request: /guestAction.jsp", which is more than the

configured time (StuckThreadMaxTime) of "60" seconds.>

<2008-4-22 上午04时35分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT

hread: '12' for queue: 'weblogic.kernel.Default' has been busy for "111" seconds

working on the request "Http Request: /guestAction.jsp", which is more than the

configured time (StuckThreadMaxTime) of "60" seconds.>

<2008-4-22 上午04时36分18秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteT

hread: '12' for queue: 'weblogic.kernel.Default' has been busy for "171" seconds

working on the request "Http Request: /guestAction.jsp", which is more than the

configured time (StuckThreadMaxTime) of "60" seconds.>

2、 判断可能存在部分sql语句未优化，造成执行时间过长（request超时）造成挂死

3、 解决

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

参数 开发模式默认值 产品模式默认值

Execute Queue: Thread Count 15 threads 25 threads

JDBC Connection Pool: MaxCapacity 15 connnections 25 connections

通过启动管理控制台，在域（如：mydomain）> 配置 > 常规选择产品模式。

修改了server-myserver参数中的threadcount参数，按照cpu数量，修改为100

修改jdbc数据库连接池，修改为初始15，最大100。

晚间进行跟踪，系统运行正常，高峰时段，尤其是早晨的高峰时段，系统没有再出现挂死的问题。

早晨点击页面查询发现有时会出现页面无法访问的情况。

跟踪发现weblogic最高时有100多并发，同时注意到内存占用比较高，检查发现，原来内存配置较低。

检查原配置文件：

:bea

if "%PRODUCTION_MODE%" == "true" goto

bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms96m -Xmx256m

set

JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto

continue

:bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms128m

-Xmx256m

goto continue

:sun

if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode

set

JAVA_VM=-client

set MEM_ARGS=-Xms32m -Xmx200m -XX:MaxPermSize=128m

set

JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto

continue

:sun_prod_mode

set JAVA_VM=-server

set MEM_ARGS=-Xms32m

-Xmx200m -XX:MaxPermSize=128m

goto continue

很明显配置为96m，最高256m。修改后的参数：

修改后结果为

:bea

if "%PRODUCTION_MODE%" == "true" goto

bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms256m -Xmx768m

set

JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto

continue

:bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms256m

-Xmx768m

goto continue

:sun

if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode

set

JAVA_VM=-client

set MEM_ARGS=-Xms256m -Xmx768m -XX:MaxPermSize=128m

set

JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto

continue

:sun_prod_mode

set JAVA_VM=-server

set MEM_ARGS=-Xms256m

-Xmx768m -XX:MaxPermSize=128m

goto continue

:continue

最低256，最高768.查看跟踪信息比较调整前后性能：

调整前内存

调整后情况：

现在垃圾回收不那么频繁了，整体稳定性应该有好处。再频繁打开一个页面的情况下，页面仍然能正常显示。
第二种解决办法：

最近生产环境下的系统经常出现以下的错误提示，

####<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）优化程序，减少处理时间。
第三种解决办法：
最近，服务器weblogic经常报异常：

<Error> <WebLogicServer> <BEA-000337>

<[STUCK]ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'has been busy for "640" seconds working on the request "Http Request: /jsp/cn/modelshow/m_hbrow.jsp", which is more than the configured time (StuckThreadMaxTime) of "600"seconds.

该异常出现的原因是资源请求的时间超出了weblogic设定的600s，造成资源排队请求，如果类似的操作很多的话，那么会造成大面积的资源请求队列，从而引起weblogic无法正常提供服务，严重时引起weblogic崩溃。那么这种原因是如何导致的呢？

首先，我们从测试服务器上发现，出现这种情况的原因是因为该请求的时间过长，于是从该请求的数据处理过程入手进行分析，发现该请求的sql语句，在sql/plus下执行时间过长，如下：

select c.*

from (

select t.*,rownum r

from (

select RGGT_ID,CPMC,PPMC,TITLE,MTMC,

MTRQ,WZZT,LRRQ,INFO_SIGN,ZYMC,BRIEF

from co1003_2239_data

where (1=1)

and (

INFO_SIGN in ('网络新闻','媒体电子版','品牌新闻')

and PPMC <> '业内动态'

)

order by mtrq desc,ppmc desc

) t

) c

where rownum<21

该表大概225W数据，在sql/plus下执行时间超长，造成请求weblogic反应时间超出默认值，从而引起资源排队请求的问题，引起服务器不稳定运行。那么出现了这种问题，怎么解决呢？我们的解决方法是对该sql语句进行优化处理：

1:对INFO_SIGN,PPMC等字段建立规范表，从数据库中进行查询，尽量减少in的使用

2:对<>等操作符不使用,使用> or <等方式来代替

3:尽量减少排序order by，rownum的使用，只在关键时刻进行使用，其他时刻能够不使用的就不进行使用。

通过以上方式来减少资源请求时间，从而减少以上异常的发生，来保证服务器的正常运行。

转自：/article/10024696.html