一次weblogic調優的經過

專案組反應資料庫有問題， 檢查發現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.檢視跟蹤資訊比較調整前後效能： 調整前記憶體 調整後情況： 現在垃圾回收不那麼頻繁了，整體穩定性應該有好處。再頻繁開啟一個頁面的情況下，頁面仍然能正常顯示。

第二種解決辦法：

最近生產環境下的系統經常出現以下的錯誤提示，  ####<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的使用，只在關鍵時刻進行使用，其他時刻能夠不使用的就不進行使用。  通過以上方式來減少資源請求時間，從而減少以上異常的發生，來保證伺服器的正常執行。