秋日里的萤火虫
BlogJava
首页
新随笔
新文章
联系
聚合
管理
posts - 42,comments - 83,trackbacks - 0
<
2011年3月
>
日
一
二
三
四
五
六
27
28
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
8
9
本Blog文章为fjin原创,转载请注明出处及作者. MSN: jinfh77@hotmail.com
常用链接
我的随笔
我的评论
我的参与
最新评论
留言簿
(16)
给我留言
查看公开留言
查看私人留言
随笔分类
Database (5)
FJin Dev (1)
Java Technology (7)
Sharing(1)
Unix && Linux
Weblogic (26)
随笔档案
2013年10月 (1)
2011年3月 (1)
2010年9月 (1)
2009年12月 (1)
2009年9月 (4)
2009年8月 (2)
2009年7月 (3)
2009年6月 (5)
2009年5月 (2)
2009年4月 (3)
2009年2月 (2)
2009年1月 (3)
2008年12月 (1)
2008年11月 (4)
2008年10月 (2)
2008年9月 (7)
文章分类
Database
FJin Dev
Java Technology
Unix && Linux
Weblogic
文章档案
2009年1月 (1)
搜索
最新评论
1. re: Weblogic10.3.5 数据库连接被异常回收问题解析
感觉写的非常好,很有用
--Celia_Chung
2. re: 和JMS Message Cosumer相关的几个问题[未登录]
评论内容较长,点击标题查看
--daniel
3. re: 关于Java中的递归调用
递归有没在详细的解释呢
--maco
4. re: 关于weblogic中使用Dom4j、Xerces导致执行线程挂起的问题
niu
--,,,
5. reool shrinking(disabling)问题分析
我只能旁观了,发表不了任何意见哈,因为不懂。
--power cord
阅读排行榜
1. java.lang.ClassNotFoundException和java.lang.NoClassDefFoundError的区别(9664)
2. 关于通过JDBC调用SQLServer 存储过程出现“服务器无法继续该事务的问题”----[SQLServer]The server failed to resume the transaction. Desc:**************(8992)
3. Weblogic10.3.5 数据库连接被异常回收问题解析(7622)
4. weblogic92连接池的连接数异常问题(7089)
5. Weblogic Apache Plugin由HALF_OPEN_SOCKET_RETRY引起的“No backend server available”(6620)
评论排行榜
1. 关于JMS Message Pending的问题(9)
2. Weblogic中因为IP变更导致SubCoordinator not available,Transaction RollbackException问题调查(7)
3. 浅析weblogic10 plugin中的DynamicServerList (6)
4. JVM TI学习(1)----如何中断weblogic中stuck thread(6)
5. Weblogic Apache Plugin由HALF_OPEN_SOCKET_RETRY引起的“No backend server available”(5)
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的逻辑如下:
1
//
check and process test hang
2
private
void
checkHang()
throws
ResourceDisabledException
3
{
4
TestRecord checkRecord
=
getCheckRecord();
5
boolean
hanging
=
suspectHang(checkRecord);
6
int
loopCount
=
0
;
7
while
(hanging
&&
(loopCount
<
SLEEP_COUNT))
{
8
try
{Thread.sleep(getCurrentTypicalTime());}
catch
(Exception e)
{}
9
10
hanging
=
checkRecord.equals(getCheckRecord());
11
loopCount
++
;
12
}
13
14
//
still hanging, disable the pool
15
if
(hanging)
{
16
disabledUponHangTestFailure
=
true
;
17
try
{suspend(
false
);}
catch
(Throwable ignore)
{}
18
try
{destroyAllResources(OP_POOL_PURGE);}
catch
(Throwable ignore)
{}
19
20
}
21
}
当
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
走走停停又三年
阅读(2838)
评论(1)
编辑
收藏
所属分类:
Weblogic
FeedBack:
#
reool shrinking(disabling)问题分析
2011-03-22 15:34 |
power cord
我只能旁观了,发表不了任何意见哈,因为不懂。
回复
更多评论
新用户注册
刷新评论列表
只有注册用户
登录
后才能发表评论。
网站导航:
博客园
IT新闻
知识库
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相关的几个问题