日志报数据源连接池满如何查因?

问题描述:

    (1)应用首页能轻松打开,但登陆的时候(与数据库打交道)迟迟没有响应!
    (2)此时,杀几个javacore,并从javacore中可以看出大部分线程来到数据源连接的请求时,就止步了:
    "Servlet.Engine.Transports : 24501" (TID:0x78E86030, sys_thread_t:0x55801E28, state:CW, native ID:0
        at java.lang.Object.wait(Native Method)                                                        
        at com.ibm.ejs.j2c.poolmanager.FreePool.queueRequest(FreePool.java(Compiled Code))            
        at com.ibm.ejs.j2c.poolmanager.FreePool.createOrWaitForConnection(FreePool.java(Compiled Code))
        at com.ibm.ejs.j2c.poolmanager.PoolManager.reserve(PoolManager.java(Compiled Code))            
        at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java(Compiled Code))  
        at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java(Compiled Code))
        ... ...

    (3)再查看同时间段的SystemOut.log,发现包了大量的数据源申请失败或超时的异常,并有线程被Hung的现象:
    677308f2 FreePool      E J2CA0045E: Connection not available while invoking method queueRequest for resource jdbc/ABCDataSource.                                                                                       
    180908f4 FreePool      E J2CA0045E: Connection not available while invoking method queueRequest for resource jdbc/AEPDataSource.                                                                                       
    180908f4 ConnectionMan E J2CA0020E: The Connection Pool Manager could not allocate a Managed Connection: com.ibm.websphere.ce.j2c.ConnectionWaitTimeoutException: Connection not available, Timed out waiting for 182463
    ... ...

     1a8489f ThreadMonitor W WSVR0605W: Thread "Servlet.Engine.Transports : 24657" (3e2fc8f7) has been active for 729,663 milliseconds and may be hung.  There are 3 threads in total in the server that may be hung.

    (4)名为“jdbc/ABCDataSource”的数据源线程池的范围是0-150,并且已经是群集,下有两个server,所以这个线程池数量是够用的了。

提问:
    请问,针对该种线程池满而导致应用不能访问的情况,请问如何能够找出吞噬线程池的“元凶”?即如何把大量开销连接的类和方法找出来呢?

    请大家参与讨论!特请懂看日志的高手不吝赐教!咔咔,谢谢~
参与13

12同行回答

独孤千殇独孤千殇技术支持11
was连接池泄漏特别不好找。如果不能从代码上发现,只能设置时效超时参数,比如3600秒,让was自动回收未关闭的连接。显示全部

was连接池泄漏特别不好找。如果不能从代码上发现,只能设置时效超时参数,比如3600秒,让was自动回收未关闭的连接。

收起
互联网服务 · 2022-02-16
浏览687
还是要结合日志和javacore,细心和耐心的找出可疑的代码,第一判断是否都有关闭连接,第二判断业务方法是否真的有太多的创建连接的活儿了,能不能改进一种实现的方式,例如缓存。谢谢大家:)...显示全部
还是要结合日志和javacore,细心和耐心的找出可疑的代码,第一判断是否都有关闭连接,第二判断业务方法是否真的有太多的创建连接的活儿了,能不能改进一种实现的方式,例如缓存。
谢谢大家:)收起
2009-02-11
浏览1495
luckyleoluckyleo项目经理山东联博软件有限公司
看一下那个应用在用jdbc/ABCDataSource,然后初步分析一下,这个应用中那一块用的数据库连接比较多,然后查看一下应用程序显示全部
看一下那个应用在用jdbc/ABCDataSource,然后初步分析一下,这个应用中那一块用的数据库连接比较多,然后查看一下应用程序收起
政府机关 · 2009-02-11
浏览1729
谢谢luckyleo!有手工产生几个javacore,如题所述,javacore中看到大部分线程都是在等连接。但是等连接的应用中则是五花百门。显示全部
谢谢luckyleo!
有手工产生几个javacore,如题所述,javacore中看到大部分线程都是在等连接。但是等连接的应用中则是五花百门。收起
2009-02-11
浏览1617
应该可以排除6楼xz43关于数据库提供的最大连接数不足的可能。因为如果数据库最大的连接数不足了,在SystemOut.log中会有sql的报错出来的,会有对应sqlcode出来。但目前来说没有这样的报错。所以应该还是应用中的连接存在没有释放的地方。哈哈,还有方法能查出原因吗?大家还是没...显示全部
应该可以排除6楼xz43关于数据库提供的最大连接数不足的可能。
因为如果数据库最大的连接数不足了,在SystemOut.log中会有sql的报错出来的,会有对应sqlcode出来。但目前来说没有这样的报错。
所以应该还是应用中的连接存在没有释放的地方。
哈哈,还有方法能查出原因吗?大家还是没有说到如何从日志中来查因的方法呢~收起
2009-02-11
浏览1633
xz43xz43系统架构师pantosoft
可能是因为你这边配置的最大连接数150×2大于数据库能提供的最大连接数,造成连接池中多余的连接始终不能得到连接。当然,也得排除是否连接没释放什么得。显示全部
可能是因为你这边配置的最大连接数150×2大于数据库能提供的最大连接数,造成连接池中多余的连接始终不能得到连接。当然,也得排除是否连接没释放什么得。收起
政府机关 · 2009-02-11
浏览1659
嗯嗯,很感谢楼上!方法2开trace确实是好方法,但是对于生产系统来说,也是比较危险的。方法3也只能监控出线程池的使用情况,相当于回演了,但是依然不能定位到问题的根源。请问能从现有的日志中定位到产生问题的地方么?或者是否还有更好的方法?咔咔,谢谢~...显示全部
嗯嗯,很感谢楼上!
方法2开trace确实是好方法,但是对于生产系统来说,也是比较危险的。
方法3也只能监控出线程池的使用情况,相当于回演了,但是依然不能定位到问题的根源。
请问能从现有的日志中定位到产生问题的地方么?或者是否还有更好的方法?咔咔,谢谢~收起
2009-02-11
浏览1634
luckyleoluckyleo项目经理山东联博软件有限公司
如果在生产的时候打开trace,后果不堪想象,但是如果能在打开trace后产生dump和javacore,可以有利于问题的分析,目前我所知道的,只有在javacore中知道那个线程出现问题,dump中知道那个时候,什么类出现问题。最好移植生产机的环境到测试机上,通过longrun的方式重现问题,可以是所有应...显示全部
如果在生产的时候打开trace,后果不堪想象,但是如果能在打开trace后产生dump和javacore,可以有利于问题的分析,目前我所知道的,只有在javacore中知道那个线程出现问题,dump中知道那个时候,什么类出现问题。
最好移植生产机的环境到测试机上,通过longrun的方式重现问题,可以是所有应用,也可以是每一个应用进行测试,进行逐个排除。当然这种方法不是最好的,希望大家能提出更好的方法。
个人认为最好的解决办法就是问题出来了,生产机宕了,hoho,不过这个需要跟客户提前打好招呼,否则问题只能是一点点地排除。收起
政府机关 · 2009-02-11
浏览1672
hrdedehrdede软件开发工程师信城通数码科技
1、是数据库连接池使用满了,临时的解决方案是增加数据库连接池的大小。2、对应用服务器开通trace功能,跟踪线程在做什么?3、通知程序员,看是否有未关闭的连接。另外可以通过tovili软件检查当前数据库连接的数、回收的连接数、等待连接的数等信息...显示全部
1、是数据库连接池使用满了,临时的解决方案是增加数据库连接池的大小。

2、对应用服务器开通trace功能,跟踪线程在做什么?

3、通知程序员,看是否有未关闭的连接。另外可以通过tovili软件检查当前数据库连接的数、回收的连接数、等待连接的数等信息收起
互联网服务 · 2009-02-11
浏览1699
谢谢楼上!不一定是客户端登陆耗尽了该线程池,客户端登陆不上,只是一个线程池满了之后的表象。呵呵,上边有多个应用的许多类中都有用到该线程池的,所以我是想请教诸位,如何能通过日志,定位到究竟是哪个类的哪些方法没有释放连接,或是大量耗用连接?...显示全部
谢谢楼上!
不一定是客户端登陆耗尽了该线程池,客户端登陆不上,只是一个线程池满了之后的表象。
呵呵,上边有多个应用的许多类中都有用到该线程池的,所以我是想请教诸位,如何能通过日志,定位到究竟是哪个类的哪些方法没有释放连接,或是大量耗用连接?收起
2009-02-11
浏览1623

提问者

擅长领域: 中间件

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2009-02-11
  • 关注会员:1 人
  • 问题浏览:5454
  • 最近回答:2022-02-16
  • X社区推广