項目組反應數(shù)據(jù)庫有問題，
檢查發(fā)現(xiàn)sga還用的默認參數(shù)，緩沖區(qū)命中率很低。根據(jù)系統(tǒng)內存調整后，好像系統(tǒng)正常了。數(shù)據(jù)庫調整就算是結束了
一天后，我再登這個數(shù)據(jù)庫的時候，發(fā)現(xiàn)一個提示說線程已經(jīng)超過限制，不允許再登錄。然后我去修改了process到250，增加并發(fā)連接數(shù)。然后重啟了數(shù)據(jù)庫。當天沒發(fā)生什么事情，第二天，發(fā)現(xiàn)250又被撐滿了，這個時候，我就開始換衣中間件有問題，登入中間件那邊看了下日志，一直報錯，提示無法打開新的連接。一般來說，中間件連接數(shù)據(jù)庫能開10個都算可以了。至少websphere是這樣，weblogic應該差不多。然后修改了一下，調整了weblogic的連接池，修改最大連接到100.
1、 報錯信息
<2008-
4-22 上午0
4時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 上午0
4時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 上午0
4時3
4分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 上午0
4時3
4分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 上午0
4時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 上午0
4時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 上午0
4時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ōu)化，造成執(zhí)行時間過長（request超時）造成掛死
3、 解決
開發(fā)模式和產(chǎn)品模式的一些參數(shù)的默認值不同，可能會對性能造成影響，下面是對性能有影響的參數(shù)列表：
參數(shù) 開發(fā)模式默認值 產(chǎn)品模式默認值
Execute
Queue: Thread Count 15 threads 25 threads
JDBC Connection Pool: MaxCapacity 15 connnections 25 connections
通過啟動管理控制臺，在域（如：mydomain）> 配置 > 常規(guī)選擇產(chǎn)品模式。
修改了server-myserver參數(shù)中的threadcount參數(shù)，按照cpu數(shù)量，修改為100
修改jdbc數(shù)據(jù)庫連接池，修改為初始15，最大100。
晚間進行跟蹤，系統(tǒng)運行正常，高峰時段，尤其是早晨的高峰時段，系統(tǒng)沒有再出現(xiàn)掛死的問題。
早晨點擊頁面查詢發(fā)現(xiàn)有時會出現(xiàn)頁面無法訪問的情況。
跟蹤發(fā)現(xiàn)weblogic最高時有100多并發(fā)，同時注意到內存占用比較高，檢查發(fā)現(xiàn)，原來內存配置較低。
檢查原配置文件：
: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ù)：
修改后結果為
: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.查看跟蹤信息比較調整前后性能：
調整前內存
調整后情況：
現(xiàn)在垃圾回收不那么頻繁了，整體穩(wěn)定性應該有好處。再頻繁打開一個頁面的情況下，頁面仍然能正常顯示。
最近，服務器weblogic經(jīng)常報異常：
<Error> <WebLogicServer> <
BEA-000337>
<[
STUCK]
ExecuteThread: '0'
for queue: 'weblogic.kernel.Default (self-tuning)'has been busy
for "6
40" 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)的原因是資源請求的時間超出了weblogic設定的600s，造成資源排隊請求，如果類似的操作很多的話，那么會造成大面積的資源請求隊列，從而引起weblogic無法正常提供服務，嚴重時引起weblogic崩潰。那么這種原因是如何導致的呢？
首先，我們從測試服務器上發(fā)現(xiàn)，出現(xiàn)這種情況的原因是因為該請求的時間過長，于是從該請求的數(shù)據(jù)處理過程入手進行分析，發(fā)現(xiàn)該請求的sql語句，在sql/plus下執(zhí)行時間過長，如下：
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)絡新聞','媒體電子版','品牌新聞')
and PPMC <> '業(yè)內動態(tài)'
)
order by mtrq desc,ppmc desc
) t
) c
where rownum<21
該表大概225W數(shù)據(jù)，在sql/plus下執(zhí)行時間超長，造成請求weblogic反應時間超出默認值，從而引起資源排隊請求的問題，引起服務器不穩(wěn)定運行。那么出現(xiàn)了這種問題，怎么解決呢？我們的解決方法是對該sql語句進行優(yōu)化處理：
1:對INFO_SIGN,PPMC等字段建立規(guī)范表，從數(shù)據(jù)庫中進行查詢，盡量減少in的使用
2:對<>等操作符不使用,使用> or <等方式來代替
3:盡量減少排序order by，rownum的使用，只在關鍵時刻進行使用，其他時刻能夠不使用的就不進行使用。
通過以上方式來減少資源請求時間，從而減少以上異常的發(fā)生，來保證服務器的正常運行。
