WEBLOGIC串連Oracle RAC 的負載平衡測試____Oracle

要進行壓力測試，中介軟體使用WEBLOGIC 816 ，資料庫版本為11.1.0.6 RAC ，壓力測試工具為LOADRUNNER 8.0 。測試單一實例與RAC 環境各個節點的負載情況。

 

 

在WEBLOGIC 上配置了一個多池，利用WEBLOGIC 提供的負載平衡策略，將並發均衡的分別到兩個節點上。

但是測試發現，一旦運行 了一段時間，所有的壓力都會載入到一個節點上，而另一個節點上機會沒有任何的壓力。

通過資料庫中查詢到的結 果如下：

SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;

INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 6
1 ACTIVE 1
2 ACTIVE 147
2 INACTIVE 3

WEBLOGIC 的並發設定為150 ，而LOADRUNNER 並發為200 ，Oracle 每 個執行個體的SESSION 為600 。

可以看到，基本上壓力完 全集中在執行個體2 上。執行個體1 上處於空閑狀態，如果壓力測試已耗用時間足夠長，可能在短時間內執行個體1 上的ACTIVE 串連能達到二、三十左右，但是很快又全部釋放。

SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;

INST_ID STATUS COUNT(*)
---------- -------- ----------
1 ACTIVE 20
1 INACTIVE 54
2 ACTIVE 121
2 INACTIVE 28

測試了多次，結果都很類 似，壓力幾乎完全集中到一個節點上。不過不見得每次壓力都是在節點2 上， 很有可能在WEBLOGIC 服務重啟之後，下次測試開始，所有 的壓力都集中到節點1 上。這說明問題應該不是兩個節點的硬體處 理不平衡造成的。

這個測試的是長時間運行 的查詢，而對於快速相應的INSERT 語句，可以看到兩個節點 上都有很少的ACTIVE 的會話。這時因為交易處理很短暫，不 可能在短時間內使得WEBLOGIC 的並發跑滿，因此這種情況 沒有問題。

SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;

INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 50
1 ACTIVE 1
2 ACTIVE 1
2 INACTIVE 98

對於長時間查詢的情況，WEBLOGIC 的LOAD-BALANCING 策略似乎存在問題，導致兩個節點壓力出現傾斜。開始認為可能是由於WEBLOGIC 的版本太低導致了問題的產生，於是將WEBLOGIC 升級到了最新的版本10.3 ，可是測試結果依舊。

由於前面測試使用的都是WEBLOGIC 的LOAD-BALANCING 策略進行的，嘗試了一下HING-AVAILABILITY 策略，發現這個策略倒是和它本身的名稱更相符一些，但是也存在一定的問題。 這個策略會優先MULIT POOL 中的第一個串連池，如果第一個串連池可以串連，就不使用第二個串連池。即使並發使用者太多，導致很多連線逾時的錯誤，WEBLOGIC 也不會去嘗試使用第二個串連池。當後台關閉執行個體1 ，導致串連池1 的串連失敗，這時WEBLOGIC 開 始使用第二個串連池。一旦執行個體1 啟動，WEBLOGIC 檢測到串連池1 可用，馬上所有的串連都會從串連池2 上轉移到串連池1 ，恢複到執行個體1 關 閉之前的情況。基於上面的情況，感覺WEBLOGIC 只是實現 了串連池的優先順序設定，而不是真正意義上的HIGH-AVAILABILITY 。

扯遠了，下面繼續說WEBLOGIC 的LOAD-BALANCING 。由於升級到最新版本都無法解決這個問題，只好在網路上搜尋，結果發現不少相似的 案例。不過沒有發現解決方案。

不過在metalink 裡面的一篇文章提到可以在WEBLOGIC 裡面的URL=”jdbc:oracle:thin@” 後面直接使用Oracle 的tnsnames.ora 中 的配置。

比如這裡配置URL=”jdbc:oracle:thin@ (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=172.0.2.58) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP) (HOST=172.0.2.59) (PORT=1521)) (LOAD_BALANCE=yes)(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=rac11g.us.oracle.com))”

這種方式實際上繞過了WEBLOGIC 的負載平衡機制，而直接使用了RAC 的負載平衡策略，結果測試結果如下：

SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;

INST_ID STATUS COUNT(*)
---------- -------- ----------
1 ACTIVE 75
1 INACTIVE 6
2 ACTIVE 75
2 INACTIVE 5

Oracle 的負載平衡的實現還是比較好的，基本上兩個節點的負載差別很小。對於負載較小的情況也同樣適用：

SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;

INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 8
1 ACTIVE 1
2 ACTIVE 2
2 INACTIVE 7

測試結果發現，要想在任 何情況下都獲得比較理想的負載平衡，最好使用Oracle 的負 載均衡策略，而不要使用WEBLOGIC 的多池提供的LOAD-BALANCING 策略。