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

检讨创造sga还用的默认参数,缓冲区命中率很低。
根据系统内存调度后,彷佛系统正常了。
数据库调度就算是结束了

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

weblogicjsp修改生效weblogic调优的经由 JavaScript

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的利用,只在关键时候进行利用,其他时候能够不该用的就不进行利用。

通过以上办法来减少资源要求韶光,从而减少以上非常的发生,来担保做事器的正常运行。