weblogic調優的通過

項目組反應數據庫有問題，
檢查發現sga還用的默認參數，緩衝區命中率很低。根據系統內存調整後，好像系統正常了。數據庫調整就算是結束了
一天後，我再登這個數據庫的時候，發現一個提示說線程已經超過限制，不容許再登陸。而後我去修改了process到250，增長併發鏈接數。而後重啓了數據庫。當天沒發生什麼事情，次日，發現250又被撐滿了，這個時候，我就開始換衣中間件有問題，登入中間件那邊看了下日誌，一直報錯，提示沒法打開新的鏈接。通常來講，中間件鏈接數據庫能開10個都算能夠了。至少websphere是這樣，weblogic應該差很少。而後修改了一下，調整了weblogic的鏈接池，修改最大鏈接到100.
一、 報錯信息
<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.>
二、 判斷可能存在部分sql語句未優化，形成執行時間過長（request超時）形成掛死
三、 解決
開發模式和產品模式的一些參數的默認值不一樣，可能會對性能形成影響，下面是對性能有影響的參數列表：
參數 開發模式默認值 產品模式默認值
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的使用，只在關鍵時刻進行使用，其餘時刻可以不使用的就不進行使用。

經過以上方式來減小資源請求時間，從而減小以上異常的發生，來保證服務器的正常運行。