登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

li.angshan 的博客

关注数据计算领域

 
 
 

日志

 
 
 
 

转载 weblogic 连接rac  

2009-10-29 12:04:10|  分类: oracle RAC技术 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

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

 

 

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

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

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

SQL> SELECT INST_ID, STATUS, COUNT(*)ITP 个人空间\?+G\U\n.K\Z:q
  2  FROM GV$SESSIONITP 个人空间)^\o\?/M:u\?\W:@\r
  3  WHERE USERNAME = 'NDMAIN'
~'M2h\|;V(N\p#n\q0  4  GROUP BY INST_ID, STATUS;

   INST_ID STATUS     COUNT(*)
*e0d\s\x\i\t\s$F0---------- -------- ----------ITP 个人空间 x$s6O X'T X\{\w
         1 INACTIVE          6
2H;c O+V#         1 ACTIVE            1ITP 个人空间$j-O#w\[\G1^\001N
         2 ACTIVE          147
\001b\q\h\U\014Y&t z0         2 INACTIVE          3

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

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

SQL> SELECT INST_ID, STATUS, COUNT(*)
/ix\|\y$B\f)G0  2  FROM GV$SESSION
P9j3Z*[*F&e&L2P3t0  3  WHERE USERNAME = 'NDMAIN'
\011w\U;B7^\005q*}*`0  4  GROUP BY INST_ID, STATUS;

   INST_ID STATUS     COUNT(*)
\|\p v4j:S0---------- -------- ----------
\014]9s9] C l0         1 ACTIVE           20ITP 个人空间9s(Z\014|0} |\BY'_.g
         1 INACTIVE         54
*W/\}\01BX\015T4E0         2 ACTIVE          121ITP 个人空间\01At;i p1f1G2@\Z\n
         2 INACTIVE         28

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

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

SQL> SELECT INST_ID, STATUS, COUNT(*)
\`8d\~,p\006B0[0  2  FROM GV$SESSION
5B\m J\019^.c0  3  WHERE USERNAME = 'NDMAIN'
-e) [)V\005B9z0  4  GROUP BY INST_ID, STATUS;

   INST_ID STATUS     COUNT(*)
r.L a}-s\e#m*h;L\006P0---------- -------- ----------ITP 个人空间\014{\t.f\016Z\01BC2r\015e
         1 INACTIVE         50
5j,L2D/i\002t\006N'O\@1V#@\003a\a0         1 ACTIVE            1ITP 个人空间)w&Q0o\014h&j\`\019k2k
         2 ACTIVE            1ITP 个人空间\01Bz\_\[I\L\019V0X _\V\~
         2 INACTIVE         98

对于长时间查询的情况,WEBLOGICLOAD-BALANCING策略似乎存在问题,导致两个节点压力出现倾斜。开始认为可能是由于WEBLOGIC的版本太低导致了问题的产生,于是将WEBLOGIC升级到了最新的版本10.3,可是测试结果依旧。

由于前面测试使用的都是WEBLOGICLOAD-BALANCING策略进行的,尝试了一下HING-AVAILABILITY策略,发现这个策略倒是和它本身的名称更相符一些,但是也存在一定的问题。这个策略会优先MULIT POOL中的第一个连接池,如果第一个连接池可以连接,就不使用第二个连接池。即使并发用户太多,导致很多连接超时的错误,WEBLOGIC也不会去尝试使用第二个连接池。当后台关闭实例1,导致连接池1的连接失败,这时WEBLOGIC开始使用第二个连接池。一旦实例1启动,WEBLOGIC检测到连接池1可用,马上所有的连接都会从连接池2上转移到连接池1,恢复到实例1关闭之前的情况。基于上面的情况,感觉WEBLOGIC只是实现了连接池的优先级设置,而不是真正意义上的HIGH-AVAILABILITY

扯远了,下面继续说WEBLOGICLOAD-BALANCING。由于升级到最新版本都无法解决这个问题,只好在网络上搜索,结果发现不少相似的案例。不过没有发现解决方案。

不过在metalink里面的一篇文章提到可以在WEBLOGIC里面的URL=”jdbc:oracle:thin@”后面直接使用Oracletnsnames.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(*)
\J\M5L4W\015A9K"r\C\011K.V0  2  FROM GV$SESSION
8C\001C f L;r0  3  WHERE USERNAME = 'NDMAIN'
|\01Ab"}\^'B(~0  4  GROUP BY INST_ID, STATUS;

   INST_ID STATUS     COUNT(*)
\002P"~\015w7}\f\015@'Ut0---------- -------- ----------
!d7a(p o7p(W0         1 ACTIVE           75
\006t `\006K\016J!k\001S7b0         1 INACTIVE          6ITP 个人空间(a\o7E"i\|\q*Y
         2 ACTIVE           75ITP 个人空间\r6c6]\m\P"|\014p\d\014s%N
         2 INACTIVE          5

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

SQL> SELECT INST_ID, STATUS, COUNT(*)
N:u\001_#v(?\\6K0  2  FROM GV$SESSIONITP 个人空间\X,` W\y!O
  3  WHERE USERNAME = 'NDMAIN'
8N\011i\A7W,~3N\016U\_\016g_0  4  GROUP BY INST_ID, STATUS;

   INST_ID STATUS     COUNT(*)ITP 个人空间\?/O!X/_"@ F
---------- -------- ----------
2j;p\L g h1k-x\019S\014O0         1 INACTIVE          8ITP 个人空间9_`\015j$G7i+H
         1 ACTIVE            1
\011x!N"C+b&b3o0         2 ACTIVE            2
8z\002I\006D l'V1?/~0         2 INACTIVE          7

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

  评论这张
 
阅读(194)| 评论(1)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018