項目組反應數據庫有問題，
檢查發現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.查看跟蹤信息比較調整前后性能：
調整前內存
調整后情況：
現在垃圾回收不那么頻繁了，整體穩定性應該有好處。再頻繁打開一個頁面的情況下，頁面仍然能正常顯示。