posts - 42,comments - 83,trackbacks - 0


          
	

          


          
	
					


          
	
	 
          

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

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

          
                  當(dāng)一個連接被測試后（在測試結(jié)果返回之前），測試記錄（TestRecord）會被記錄到一個叫做currentlyRunningTests的TreeSet變量中，當(dāng)測試返回后，無論結(jié)果成功與否，這個record都會被從currentlyRunningTests中刪除。在連接被測試之前，checkHang()被調(diào)用，checkHang的邏輯如下：
          
          

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

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

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

          
          

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

          







          
	    
    


          
FeedBack:

          
	

		
          
			
          # reool shrinking(disabling)問題分析
          
			
          
				2011-03-22 15:34 | power cord
          
				
          我只能旁觀了，發(fā)表不了任何意見哈，因為不懂。  回復(fù)  更多評論
            
          
			
          
			
			
		
          
	








          








          

				

          



    







          
        
	




主站蜘蛛池模板：
大宁县|
澄城县|
山东省|
寿光市|
合山市|
天津市|
嵩明县|
望江县|
兴宁市|
越西县|
合山市|
色达县|
广安市|
湖南省|
淮南市|
庄河市|
明星|
平乡县|
无极县|
龙陵县|
兴宁市|
保德县|
得荣县|
长泰县|
夏河县|
石台县|
囊谦县|
海伦市|
越西县|
黔南|
孟州市|
九寨沟县|
清丰县|
宁陕县|
保德县|
天长市|
崇义县|
武宁县|
东乡县|
温州市|
海伦市|