項(xiàng)目組反應(yīng)數(shù)據(jù)庫(kù)有問(wèn)題，
檢查發(fā)現(xiàn)sga還用的默認(rèn)參數(shù)，緩沖區(qū)命中率很低。根據(jù)系統(tǒng)內(nèi)存調(diào)整后，好像系統(tǒng)正常了。數(shù)據(jù)庫(kù)調(diào)整就算是結(jié)束了
一天后，我再登這個(gè)數(shù)據(jù)庫(kù)的時(shí)候，發(fā)現(xiàn)一個(gè)提示說(shuō)線程已經(jīng)超過(guò)限制，不允許再登錄。然后我去修改了process到250，增加并發(fā)連接數(shù)。然后重啟了數(shù)據(jù)庫(kù)。當(dāng)天沒(méi)發(fā)生什么事情，第二天，發(fā)現(xiàn)250又被撐滿了，這個(gè)時(shí)候，我就開(kāi)始換衣中間件有問(wèn)題，登入中間件那邊看了下日志，一直報(bào)錯(cuò)，提示無(wú)法打開(kāi)新的連接。一般來(lái)說(shuō)，中間件連接數(shù)據(jù)庫(kù)能開(kāi)10個(gè)都算可以了。至少websphere是這樣，weblogic應(yīng)該差不多。然后修改了一下，調(diào)整了weblogic的連接池，修改最大連接到100.

1、 報(bào)錯(cuò)信息

<2008-4-22 上午04時(shí)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時(shí)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時(shí)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時(shí)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時(shí)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時(shí)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時(shí)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語(yǔ)句未優(yōu)化，造成執(zhí)行時(shí)間過(guò)長(zhǎng)（request超時(shí)）造成掛死

3、 解決
開(kāi)發(fā)模式和產(chǎn)品模式的一些參數(shù)的默認(rèn)值不同，可能會(huì)對(duì)性能造成影響，下面是對(duì)性能有影響的參數(shù)列表：
參數(shù) 開(kāi)發(fā)模式默認(rèn)值 產(chǎn)品模式默認(rèn)值
Execute Queue: Thread Count 15 threads 25 threads
JDBC Connection Pool: MaxCapacity 15 connnections 25 connections
通過(guò)啟動(dòng)管理控制臺(tái)，在域（如：mydomain）> 配置 > 常規(guī)選擇產(chǎn)品模式。

修改了server-myserver參數(shù)中的threadcount參數(shù)，按照cpu數(shù)量，修改為100
修改jdbc數(shù)據(jù)庫(kù)連接池，修改為初始15，最大100。

晚間進(jìn)行跟蹤，系統(tǒng)運(yùn)行正常，高峰時(shí)段，尤其是早晨的高峰時(shí)段，系統(tǒng)沒(méi)有再出現(xiàn)掛死的問(wèn)題。
早晨點(diǎn)擊頁(yè)面查詢發(fā)現(xiàn)有時(shí)會(huì)出現(xiàn)頁(yè)面無(wú)法訪問(wèn)的情況。
跟蹤發(fā)現(xiàn)weblogic最高時(shí)有100多并發(fā)，同時(shí)注意到內(nèi)存占用比較高，檢查發(fā)現(xiàn)，原來(lái)內(nèi)存配置較低。

檢查原配置文件：
: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。修改后的參數(shù)：
修改后結(jié)果為
: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.查看跟蹤信息比較調(diào)整前后性能：

調(diào)整前內(nèi)存


調(diào)整后情況：


現(xiàn)在垃圾回收不那么頻繁了，整體穩(wěn)定性應(yīng)該有好處。再頻繁打開(kāi)一個(gè)頁(yè)面的情況下，頁(yè)面仍然能正常顯示。

第二種解決辦法：

最近生產(chǎn)環(huán)境下的系統(tǒng)經(jīng)常出現(xiàn)以下的錯(cuò)誤提示，
####<2007-7-2 下午04時(shí)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.>
該問(wèn)題是由于處理custcheckout.do請(qǐng)求超時(shí)引起的，系統(tǒng)配置的處理時(shí)間是600s，但是該線程處理了1165s后，仍然沒(méi)將請(qǐng)求釋放，所以報(bào)了這個(gè)錯(cuò)誤。如果發(fā)送該請(qǐng)求較多，很有可能會(huì)導(dǎo)致weblogic的線程阻塞，嚴(yán)重會(huì)引起weblogic掛起現(xiàn)象。
可以通過(guò)以下幾種方法解決：
1）修改StuckThreadMaxTime參數(shù)，將默認(rèn)的600s改成1200s，或者其它適合的值。
2）增大線程數(shù)，防止線程阻塞問(wèn)題。
3）優(yōu)化程序，減少處理時(shí)間。

第三種解決辦法：

最近，服務(wù)器weblogic經(jīng)常報(bào)異常：
<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.

該異常出現(xiàn)的原因是資源請(qǐng)求的時(shí)間超出了weblogic設(shè)定的600s，造成資源排隊(duì)請(qǐng)求，如果類似的操作很多的話，那么會(huì)造成大面積的資源請(qǐng)求隊(duì)列，從而引起weblogic無(wú)法正常提供服務(wù)，嚴(yán)重時(shí)引起weblogic崩潰。那么這種原因是如何導(dǎo)致的呢？

首先，我們從測(cè)試服務(wù)器上發(fā)現(xiàn)，出現(xiàn)這種情況的原因是因?yàn)樵撜?qǐng)求的時(shí)間過(guò)長(zhǎng)，于是從該請(qǐng)求的數(shù)據(jù)處理過(guò)程入手進(jìn)行分析，發(fā)現(xiàn)該請(qǐng)求的sql語(yǔ)句，在sql/plus下執(zhí)行時(shí)間過(guò)長(zhǎng)，如下：
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 ('網(wǎng)絡(luò)新聞','媒體電子版','品牌新聞')
                 and PPMC <> '業(yè)內(nèi)動(dòng)態(tài)'
                 )  
           order by mtrq desc,ppmc desc
    ) t       
) c
where rownum<21

該表大概225W數(shù)據(jù)，在sql/plus下執(zhí)行時(shí)間超長(zhǎng)，造成請(qǐng)求weblogic反應(yīng)時(shí)間超出默認(rèn)值，從而引起資源排隊(duì)請(qǐng)求的問(wèn)題，引起服務(wù)器不穩(wěn)定運(yùn)行。那么出現(xiàn)了這種問(wèn)題，怎么解決呢？我們的解決方法是對(duì)該sql語(yǔ)句進(jìn)行優(yōu)化處理：
1:對(duì)INFO_SIGN,PPMC等字段建立規(guī)范表，從數(shù)據(jù)庫(kù)中進(jìn)行查詢，盡量減少in的使用
2:對(duì)<>等操作符不使用,使用> or <等方式來(lái)代替
3:盡量減少排序order by，rownum的使用，只在關(guān)鍵時(shí)刻進(jìn)行使用，其他時(shí)刻能夠不使用的就不進(jìn)行使用。

通過(guò)以上方式來(lái)減少資源請(qǐng)求時(shí)間，從而減少以上異常的發(fā)生，來(lái)保證服務(wù)器的正常運(yùn)行。