亚洲欧洲中文日韩久久AV乱码,亚洲不卡AV影片在线播放,亚洲欧洲无卡二区视頻

WLS10.3.0中，連接測試導致的connection pool shrinking(disabling)問題分析

        問題的描述在上面，我這里簡單復述一下這個問題：當應用被加載的時候，會有大量的請求被觸發，這時可以看到連接數迅速增長到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的邏輯如下：

// 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

常用鏈接

留言簿(16)

隨筆分類

隨筆檔案

文章分類

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: Weblogic10.3.5 數據庫連接被異常回收問題解析 WLS10.3.0中，連接測試導致的connection pool shrinking(disabling)問題分析 weblogic92連接池的連接數異常問題 (二) Weblogic Apache Plugin由HALF_OPEN_SOCKET_RETRY引起的“No backend server available” weblogic92連接池的連接數異常問題如何在Weblogic的全局事務執行多線程操作關于JMS Message Pending的問題 Weblogic92中使用JDBC store存儲session時，unique constraint violated（唯一約束沖突）相關問題分析關于weblogic中jms message的狀態和JMS Message Cosumer相關的幾個問題