性能测试——记weblogic 连接池满无法链接故障诊断过程

记weblogic 连接池满无法链接故障诊断过程

前段时间公司负责建行的一个票据系统在,上线前几个分行试运行环境下,每天后台日志都会报oracle.jdbc.xa.OracleXAException,前台无法正常访问
 
通过使用weblogic的测试数据库链接,弹出无法链接提示信息,但是发现连接池使用才10个,而最大连接数60个,监控分析没有发现连接数使用满的迹象。

那个时候我们公司的老总以及客户方项目领导非常着急,都忙着找人帮忙解决,客户方也请了他们建行自己的高手过来解决,我们公司老总也打电话四处咨询
    
寻求解决方案,因为我是做性能测试的也被叫过去帮忙查看问题,第一天早上问题出现后,我第一反映就是重新设置连接数,设置最小值最大值80,然后重新清除下

JDBC缓存,那天是没发生问题了,但是第二天问题又重现了,客户方技术人员把连接数减少到60,然后设置不使用 Supports Global Transactions,那天下午

问题没在复现,项目组人员都安心了以为问题解决了。只是那时我心里纳闷了,感觉这个不能解决问题,但是当天下午没复现问题我也不能说什么,只能继续低头

查看分析日志,如果不出现说明人家是对的,也说明我的经验不足,但是万一在出现还得在找解决方案,毕竟这是我们公司负责的项目,万一真实生产环境一运行

每天都这样出问题,那这个系统就算是废了。所以还是低头继续分析问题。
 
    果然第三天问题还是出现,客户方、公司领导真的都着火了,继续打电话咨询高手,有人提出数据库连接数不足,需要设置大一些,然后重启数据库,
   
那天我还是没找出问题点,但是客户方要求根据那个高手建议去调整,我只是提了下说这样应该没效果,因为功能测试环境、性能测试环境同样配置都没出问题应该

不是这个问题,但是在这个时间段谁听啊,能解决问题就行,都是死马当活马医了。不过我当时也没想出解决方案,只能静观其变了。就这样那天下午问题没重现

在第四天早上过来时,项目组的人都在开心的认为问题解决了,可惜的事情还是发现了,第四天早上11点多的时候,突然我同事给我打电话说问题重现了。该怎么办

那时我刚好在开会,开完会回来,我重新看了下错误日志,还是报“oracle.jdbc.xa.OracleXAException” 同样的错误信息,于是我好奇的问了下,你们JDBC
    连接数是不是一开始设置错误,然后重新设置过,因为我发现使用的JDBC驱动跟报的错误提示信息不一样,那个集成配置人员说是有配置错误过,重新选择
    Database Driver ,这下我大概明白问题点了,我建议重新删除数据源重新配置一次性配置正确,一开始项目组领导还真不信,觉得这不能解决此问题。
   
  只能说我人微言轻,他们不信是正常的,一个做性能测试的哪能解决这种故障,而且请了很多资深高手都没得以解决。我看出他们的心思,就笑了笑说
 
  这是BEA官方说的,其实哪有什么官方,看都没看过,上班又不能上网,哪能去看什么官方文档,说不定官方文档也没这个问题记录呢。
 
  谁知,我一说是官方文档说的,而且加以他们实在找不出解决方案了,迫不得已,接受我的意见。
 
  就这样我着急的等了第五天的来临,第五天到下午问题还没出现,我走去问 了下领导说,今天没出现那个问题吧,领导回答很干脆是没出现,但是是因为这个项目
  周五没人用所以不会出现,我只能伪笑了回答哦,起始这个问题跟是否有人使用关系不大,就是配置错误,但是一下子说不出具体理由过来,说实话我那时
  也没说服力,反正很多时候我去解决不同项目的故障问题,很多都是凭感觉的虽然到现在每次都蒙对,但是很多都是凭直觉来做的。就这样等了几天问题没出现了。
 
  说明我的推理正确,这个项目的领导很淡定,我们公司的领导也很淡定,解决后没跟我说啥,就当没事发生,o(∩_∩)o 哈哈 ,我也跟着淡定。反正这些年解决了
  很多建行项目多年没解决的故障问题,很多领导都感觉很淡定是应该的。习惯就好,反正对我来说又积累一次故障诊断经验就行。

时间: 2024-10-13 14:06:06

性能测试——记weblogic 连接池满无法链接故障诊断过程的相关文章

数据库死锁严重引发中间件连接池满故障诊断

1.故障现象 前台系统应用无法登陆,weblogic服务器应用程序的运行状态显示为overload,线程连接池满. 2.故障原因分析 根据上述故障现象,分析基础可以确定为是Weblogic有过多的连接连到数据库,因为会话一直保持未释放,将连接池占满后,导致新的连接无法请求到连接池.在此关键是分析为什么会有大量的会话占满连接池而不释放. 3.问题分析过程 3.1 session数超过1000 Snap Id Snap Time Sessions Cursors/Session Begin Snap

weblogic连接池

1.在 使用JDBC连接池的过程中,最常见的一个问题就是连接池泄漏问题.一个池里面的资源是有限的,应用用完之后应该还回到池中,否则池中的资源会被耗尽. WebLogic Server提供了一个Inactive Connection Timeout选项,默认是60秒,如果一个连接被应用拿走之后,超过这个时间还没有还回来,WebLogic Server会强制将这个连接回收.如果应用中不存在连接泄漏的问题,则不需要这个选项.设置为0即可禁用 2.V$SESSION 记录当前连接数据库的 Session

连接池的概念

连接池的概念  1)连接池是一个进程 多个连接是在一个进程里面存储.管理的.这个进程保存所有的连接,当我们打开连接,如果有未用连接可用,则返回该连接.如果池中的连接都用完了,则创建一个新的连接保存到连接池.而但我们关闭连接的时候,连接池里面并不关闭连接,而是返回连接池中并标记为可重用的状态,等待重新连接直到等待超时.再次打开连接的时候,我们就可以重用上次的连接.如果在这个时间内没有连接请求(打开连接),这个数据库连接将被关闭,并从连接池中移除这个连接实例.如果池中连接到达了最大连接数,请求进入等

DBCP连接池使用问题

问题现象: 启动应用,访问无压力,一切正常,一段时间过后,应用访问异常. 问题分析: 1.web容器线程爆满,拒绝服务.由于应用并发量大,线程响应时间长增加,线程池连接数逐步递增直到爆满,导致应用拒绝服务. 2.通过对线程信息的分析,发现线程处理时间都卡在连接数据库中,通过对数据库服务器的检查,数据库是没有问题的. 3.通过查询服务器日志,发现数据库连接异常:连接超时. 4.查询DBCP连接池连接使用情况,空闲链接和使用链接还正常. 问题思考: 从以上信息可以确认,问题一定出在应用层,并且是应用

c3p0连接池

c3p0是第三方连接池 c3p0自动读取的配置文件 //这里可以传一个参数,不传参数默认default-config,也可以传<named-config name="itheima"> ComboPooledDataSource dataSource = new ComboPooledDataSource(); c3p0-config.xml <c3p0-config> <!-- 默认配置,如果没有指定则使用这个配置 --> <default-

生产级Nodejs开发实践-使用连接池

引言 做后端开发免不了要和一些 存储服务器, 消息服务器 等等 打交道. 起因 (传统模式, 读取数据库) 大家都知道和这些使用 tcp连接 的服务传递数据的都必须要打开 一个 连接-connection 例如我们打开一个数据库并执行一段 sql, 通常都是 connection = open "mysql://127.0.0.1:3306/db" (打开数据库,并取得持有连接的句柄) data = connection.exec "select * from table1&

号称性能最好的JDBC连接池:HikariCP

HikariCP号称是现在性能最好的JDBC连接池组件,具体的性能到底如何,我也没有仔细的测试过,不过从它现在的发展来看,其可能确实如它宣传的那样其性能高过目前所有的连接池组件.之前对连接池的记忆一直都是C3P0.DBCP.BoneCP,这三者中BoneCP的性能是最好的,C3P0的性能在现在来说确实是非常差的了,好像C3P0很久都没有更新了,所以我们应该杜绝在项目中使用C3P0,至于是否要使用HikariCP,我觉得可以尝试.HikariCP毕竟是才出来不久,其性能到底如何,也需要实践的检验,

连接池DBCP的简单使用

DBUtil工具类的设计 私有化构造方法,防止被new(很重要) 暴露一些public的方法给外界调用(很重要) 有这么两步之后,工具类基本就完成了 ·为什么要使用连接池? 在应用中,与数据建立连接,操作数据库,关闭连接.这是一件很耗费资源的.为了合理的使用资源,诞生了连接池这个东西 1.什么是连接池 连接池,顾名思义 存放连接的池子.其作用就是连接池与数据库建立长久的连接,当我们需要操作数据库的时候,不再是去主动建立连接,而是去连接池中获取链接,操作完成后,释放当前连接,资源回到连接池中,资源

jedis连接池爆满导致的服务不可用

生产环境was线程数300,jedis连接池连接数100. 在业务高峰期,查看日志发现大量could not get a resource from a pool的异常,抓取javacore文件发现was线程大量进入parked状态,查看jedis源码发现连接池底层使用common-pool实现,而common-pool其中有这样一段代码: if (p == null) { if (borrowMaxWaitMillis < 0) { p = idleObjects.takeFirst(); }