<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 42,comments - 83,trackbacks - 0
     

            問題的描述在上面,我這里簡單復述一下這個問題:當應用被加載的時候,會有大量的請求被觸發,這時可以看到連接數迅速增長到110,活動連接數也達到102。但后來發現,連接數迅速下降到40,同時看到“Failed Reserve Request Count”迅速增長。同時Oracle DBA也報告說很多新的連接被建立(遠大于之前的110)。應用開始拋出“XX connection pool is disabled”的錯誤。一段時間以后,連接池自我恢復完畢,連接重新回到110,但DBA看到連接此時沒有減少,任然維持在240左右。 

            直覺上來看,這個問題應該是連接池臨時disable或者flush導致的,而不是shrink導致(從后面的pool disable也能看出來,pool是被disable而不是shrink了),可以通過netstat看一下db端的連接狀態,應該很多處于close_wait狀態,記連接關閉請求由weblogic端發起,但截至問題發生的時刻,連接本身尚未關閉。為什么會出現連接池臨時disable的狀況呢?問題根源在于test-connections-on-reserve的設定后,當某個連接的idle時間超過
    SecondsToTrustAnIdlePoolConnection 后,這個連接在返回客戶端之前,會進行連接測試。測試之前,WLS首先會調用checkHang()來檢查之前的連接測試是否存在掛起的現象,如果掛起,我們需要disable整個connection pool,同時重新初始化這個連接池。那么什么情況下,連接測試會被視為掛起呢?

           
    當一個連接被測試后(在測試結果返回之前),測試記錄(TestRecord)會被記錄到一個叫做currentlyRunningTests的TreeSet變量中,當測試返回后,無論結果成功與否,這個record都會被從currentlyRunningTests中刪除。在連接被測試之前,checkHang()被調用,checkHang的邏輯如下:
     1  // check and process test hang
     2  private void checkHang() throws ResourceDisabledException
     3  
            當currentlyRunningTests中的記錄數超過五條的時候,第六條會被返回,否則不會返回測試記錄,即suspectHang將返回false。而當記錄數超過五條的時候,我們會拿第六條記錄作為checkHang的樣本。每次連接測試成功后,wls會將這一次的測試時間作為一個樣本時間,記錄到一個successfulTestTimes數組中,這個數組最多維護10條記錄,然后wls會這10個時間中,最長的那個作為樣本測試時間。最后再用這個樣本測試時間*TYPICAL_TIME_FACTOR(hard-coded value is 1.2)作為連接返回時間,如果我們的樣本record測試時間已經超過樣本測試時間,那么suspectHang將返回true, 否則返回false。如果suspectHang返回true,當前線程進入for循環,sleep20次(SLEEP_COUNT)后,如果測試仍然沒有返回,且currentlyRunningTests中前五個測試記錄也沒有返回的話,那么這個測試將會被視為測試掛起,這個pool就會被disable。可能引起這問題的條件是:之前的數據庫性能很好,測試都能夠迅速返回,可能測試耗時都是毫秒級的。突然某一時刻,數據庫性能急劇下降,導致測試耗時很長(當然包括前面的五條測試記錄)。WLS以之前的測試時間作為樣本時間來衡量此時此刻的測試結果,在數據庫性能下降、測試響應慢的時候,很容易被當成測試掛起來處理(即disable整個pool)。

            于是客戶端看到了pool被disable的現象,那么Pool什么時候會被重新初始化呢,pool中有一個Healh Maintainece Task,每隔五秒,這個task會啟動一次,用于檢查那些被disabled的pool,如果連接測試通過,那么這個Pool會被重新enable。

            這個實現方式不是很好,于是10.3.4中對這塊做了重新設計。我們現在看看10.3.4中是如何實現的吧!
            10.3.4引入了一個可配置變量weblogic.resourcepool.max_test_wait_secs,默認為10秒,如果通過-Dweblogic.resourcepool.max_test_wait_secs將它設為0,那么連接測試的時候,將不再做checkHang。如果這個值不是0,那么checkHang的最長等待時間將是這個指定的值,而不再像10.3.0中,最長等待時間為樣本時間*20。同時修改了TYPICAL_TIME_FACTOR,這個值由1.2變成了10,這個值得修改對suspectHang有一定影響,但影響不大,這個參數也是硬編碼的,客戶不能對它進行配置。這兩個參數中,對checkHang影響比較大的還是weblogic.resourcepool.max_test_wait_secs,所以如果碰到類似問題,可以通過適當的修改這個值來解決問題。
           

    posted on 2011-03-22 14:45 走走停停又三年 閱讀(2855) 評論(1)  編輯  收藏 所屬分類: Weblogic

    FeedBack:
    # reool shrinking(disabling)問題分析
    2011-03-22 15:34 | power cord
    我只能旁觀了,發表不了任何意見哈,因為不懂。  回復  更多評論
      
    主站蜘蛛池模板: 羞羞漫画小舞被黄漫免费| yy6080亚洲一级理论| 国产成人A人亚洲精品无码| 无码人妻一区二区三区免费视频| 日韩免费视频在线观看| 亚洲久热无码av中文字幕| 午夜色a大片在线观看免费| 亚洲国产精品美女久久久久| 免费观看的a级毛片的网站| 国产精品亚洲一区二区无码| 无码专区一va亚洲v专区在线| 色老头综合免费视频| 亚洲男人的天堂一区二区| 皇色在线免费视频| 亚洲av之男人的天堂网站 | 欧洲美女大片免费播放器视频| 又粗又大又猛又爽免费视频| 成年网在线观看免费观看网址| 亚洲欧洲日产国码av系列天堂| 99热这里只有精品免费播放| avtt天堂网手机版亚洲| 国产乱人免费视频| A毛片毛片看免费| 亚洲av永久无码精品表情包| 久久精品国产免费观看| 亚洲av日韩精品久久久久久a| 亚洲最大av无码网址| 久草福利资源网站免费| 亚洲中文久久精品无码1| 国产一区二区三区无码免费| a级在线观看免费| 亚洲人成高清在线播放| 四虎影视永久免费视频观看| 日本免费A级毛一片| 亚洲日本国产精华液| 一本久到久久亚洲综合| 日韩精品人妻系列无码专区免费 | a级片免费观看视频| 亚洲国产成人手机在线电影bd| 国产男女猛烈无遮挡免费网站 | 免费女人高潮流视频在线观看|