[转帖]WEBLOGIC连接Oracle RAC的负载均衡测试_Tomcat, WebLogic及J2EE讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  Tomcat, WebLogic及J2EE讨论区 »
总帖数
2
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 5862 | 回复: 1   主题: [转帖]WEBLOGIC连接Oracle RAC的负载均衡测试        上一篇   下一篇 
masy
注册用户
等级:少校
经验:1234
发帖:182
精华:0
注册:2011-11-4
状态:离线
发送短消息息给masy 加好友    发送短消息息给masy 发消息
发表于: IP:您无权察看 2011-11-9 15:55:17 | [全部帖] [楼主帖] 楼主

要进行压力测试,中间件使用WEBLOGIC 816,数据库版本为11.1.0.6 RAC,压力测试工具为LOADRUNNER 8.0。测试单实例与RAC环境各个节点的负载情况。

在WEBLOGIC上配置了一个多池,利用WEBLOGIC提供的负载均衡策略,将并发均衡的分别到两个节点上。

但是测试发现,一旦运行了一段时间,所有的压力都会加载到一个节点上,而另一个节点上机会没有任何的压力。

通过数据库中查询到的结果如下:

SQL> SELECT INST_ID, STATUS, COUNT(*)


g)S m:U4mD7O0  2  FROM GV$SESSIONITPUB个人空间)MSH-w@
  3  WHERE USERNAME = 'NDMAIN'ITPUB个人空间w2Lheu~0qc H/P

 4  GROUP BY INST_ID, STATUS;


   INST_ID STATUS     COUNT(*)ITPUB个人空间F7b/KP-g C

---------- -------- ----------


"dt/DOh0         1 INACTIVE          6ITPUB个人空间j6M ]~'Tp2pr o2G.R2e

 1 ACTIVE            1


v!V6HS P0tc0         2 ACTIVE          147ITPUB个人空间6wiH&_'K9D'V

 2 INACTIVE          3


WEBLOGIC的并发设置为150,而LOADRUNNER并发为200,Oracle每个实例的SESSION为600。

可以看到,基本上压力完全集中在实例2上。实例1上处于空闲状态,如果压力测试运行时间足够长,可能在短时间内实例1上的ACTIVE连接能达到二、三十左右,但是很快又全部释放。

SQL> SELECT INST_ID, STATUS, COUNT(*)ITPUB个人空间kc1YF#?ml&YJ+H
  2  FROM GV$SESSIONITPUB个人空间H'h*HG:y0]A

 3  WHERE USERNAME = 'NDMAIN'
mDn xN;b@0  4  GROUP BY INST_ID, STATUS;


   INST_ID STATUS     COUNT(*)ITPUB个人空间;J]RHB*A!b/T k

---------- -------- ----------ITPUB个人空间Y?+M8ZP i6n/W t
1 ACTIVE           20


k;o i7a!Hl0         1 INACTIVE         54ITPUB个人空间.R@"n:F)n%p7f c

 2 ACTIVE          121
1Opz2J I ?]j Q0         2 INACTIVE         28


测试了多次,结果都很类似,压力几乎完全集中到一个节点上。不过不见得每次压力都是在节点2上,很有可能在WEBLOGIC服务重启之后,下次测试开始,所有的压力都集中到节点1上。这说明问题应该不是两个节点的硬件处理不平衡造成的。

这个测试的是长时间运行的查询,而对于快速相应的INSERT语句,可以看到两个节点上都有很少的ACTIVE的会话。这时因为事务处理很短暂,不可能在短时间内使得WEBLOGIC的并发跑满,因此这种情况没有问题。

SQL> SELECT INST_ID, STATUS, COUNT(*)


Uj$ h,h\'{u0  2  FROM GV$SESSIONITPUB个人空间4R]R,T!V;S3~

 3  WHERE USERNAME = 'NDMAIN'
"OX,s&bIt)A0  4  GROUP BY INST_ID, STATUS;
INST_ID STATUS     COUNT(*)
7Z y3D)bY D.p#f0---------- -------- ----------ITPUB个人空间(A1d6k({ L ~ ])X/eu:~2\c Q


         1 INACTIVE         50ITPUB个人空间 {9hu5E9D KX%b!L +gy

 1 ACTIVE            1
`;S#c$hT^~0         2 ACTIVE            1
:i%~9`1V:Tu0         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(*)ITPUB个人空间cY7I8eId+{U(R
  2  FROM GV$SESSIONITPUB个人空间9M@8q'L1a]oF
  3  WHERE USERNAME = 'NDMAIN'
3@"v]t*Z a*v*F0  4  GROUP BY INST_ID, STATUS;

     INST_ID STATUS     COUNT(*)

v-b0Gy RLJ'Uo0---------- -------- ----------


Uy{N:nC&h~0         1 ACTIVE           75ITPUB个人空间(xYN_K2rfLA
         1 INACTIVE          6ITPUB个人空间.SU G{ W2Hp
         2 ACTIVE           75ITPUB个人空间h4T6J(B0r}0RK
         2 INACTIVE          5

Oracle的负载均衡的实现还是比较好的,基本上两个节点的负载差别很小。对于负载较小的情况也同样适用:

SQL> SELECT INST_ID, STATUS, COUNT(*)

`"WoD3m4P'nQ0  2  FROM GV$SESSION


0?5mN+~ M+PDL"m0  3  WHERE USERNAME = 'NDMAIN'ITPUB个人空间+P{7@Cz

 4  GROUP BY INST_ID, STATUS;
INST_ID STATUS     COUNT(*)
CSihO/z?1tf0---------- -------- ----------
3t7lFh0fS&i?0         1 INACTIVE          8
J0B'S,FK$}8].A d K0         1 ACTIVE            1
ac#iF!H&D u0         2 ACTIVE            2
$u4bw u@#q%l0         2 INACTIVE          7


测试结果发现,要想在任何情况下都获得比较理想的负载均衡,最好使用Oracle的负载均衡策略,而不要使用WEBLOGIC的多池提供的LOAD-BALANCING策略。




赞(0)    操作        顶端 
koei123
注册用户
等级:大校
经验:4196
发帖:16
精华:0
注册:2011-7-21
状态:离线
发送短消息息给koei123 加好友    发送短消息息给koei123 发消息
发表于: IP:您无权察看 2018-12-22 5:35:21 | [全部帖] [楼主帖] 2  楼


跟数据库的配合,一直是个关键点~~



赞(0)    操作        顶端 
总帖数
2
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论