阿里Druid数据连接池引发的线上异常解决

目录
  • 前言
  • 过程一:定位工作流
  • 过程二:定位JPA的OpenEntityManagerInViewInterceptor
  • 过程三:定位Druid,真正的罪魁祸首
  • 后记:

前言

事件起因:项目使用了activiti工作流,系统是由老的spring mvc项目改造成的spring boot项目,数据库链接池从dbcp切换到druid,新系统上线后,同事多次系统隔一段时间后数据查询就很慢,基本出不来。

由此开始了线上bug排查之路。这个问题从一开始就模糊定位到数据库层面的问题,因为只有和数据相关的操作会很慢,其他服务不受影响,并且在中午休息时没有问题,在下午刚上班后不就出现。

过程一:定位工作流

首先第一反应是看日志:日志一切正常,并没有任何异常信息抛出,然后将日志级别调整到debug,发现了一些问题,中午休息时,用户没有操作的情况下,日志一直在输出jpa的连接信息,最后定位是工作流的异步执行器在轮询,因为在spring boot环境下spring.activiti.async-executor-activate=true默认是true的,如果不需要使用可以设置为false,改完后情况依旧

过程二:定位JPA的OpenEntityManagerInViewInterceptor

使用OpenEntityManagerInViewInterceptor后服务端在接收到一个请求的时候开启EntityManager,在请求结束的时候才去关闭这个EntityManager,所以在用户数多,并发高,操作耗时的情况下会造成数据连接不够用的情况,而我们的业务有这个特征。

在spring boot环境中,OpenEntityManagerInViewInterceptor默认是开启的,然而我们使用spring.jpa.open-in-view=false关闭后,问题依旧,不过比之前的间隔时间久一点了

过程三:定位Druid,真正的罪魁祸首

使用top定位到程序pid,然后使用jstack -l 2591 >>dump.out 拿到当前堆栈快照后发现如下

"http-nio-8080-exec-54" daemon prio=10 tid=0x0000000000e61000 nid=0xcc9 waiting on condition [0x00007f4a753d4000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007a143f230> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
	at com.alibaba.druid.pool.DruidDataSource.takeLast(DruidDataSource.java:1732)
	at com.alibaba.druid.pool.DruidDataSource.getConnectionInternal(DruidDataSource.java:1330)
	at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:1198)
	at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4619)

所有的请求都被druid的获取连接操作阻塞了,最后看源码如下

因为数据链接没有释放,连接池中无可用连接,导致请求被阻塞了

到这里基本上就是真相了,最后换成spring boot自带的连接池tomcat jdbc后一切正常

后记:

定位到问题后,发现网上很多人遇到了连接泄露的情况,可见druid的官方issue,如https://github.com/alibaba/druid/issues/1160

不过druid也提供了相应的方案,如下

虽然官方说可能是应用自己导致连接未被释放导致连接泄露,但是为什么切换别家的连接池后就毛事都没有呢,元芳,你怎么看呢?

以上就是阿里Druid数据连接池引发的线上异常解决的详细内容,更多关于Druid数据连接池线上异常的资料请关注我们其它相关文章!

(0)

相关推荐

  • SpringBoot开发案例之配置Druid数据库连接池的示例

    前言 好久没有更新Spring Boot系列文章,你说忙么?也可能是,前段时间的关注点也许在其他方面了,最近项目中需要开发小程序,正好采用Spring Boot实现一个后端服务,后面会把相关的代码案例分享出来,不至于大家做小程序后端服务的时候一头雾水. 在Spring Boot下默认提供了若干种可用的连接池(dbcp,dbcp2, tomcat, hikari),当然并不支持Druid,Druid来自于阿里系的一个开源连接池,它提供了非常优秀的监控功能,下面跟大家分享一下如何与Spring Bo

  • 数据库阿里连接池 druid配置详解

    Java程序很大一部分要操作数据库,为了提高性能操作数据库的时候,有不得不使用数据库连接池.数据库连接池有很多选择,c3p.dhcp.proxool等,druid作为一名后起之秀,凭借其出色的性能,也逐渐印入了大家的眼帘.接下来本教程就说一下druid的简单使用. 首先从 http://repo1.maven.org/maven2/com/alibaba/druid/下载最新的jar包.如果想使用最新的源码编译,可以从 https://github.com/alibaba/druid下载源码,然

  • 关于数据库连接池Druid使用说明

    根据综合性能,可靠性,稳定性,扩展性,易用性等因素替换成最优的数据库连接池. Druid:druid-1.0.29 数据库 Mysql.5.6.17 替换目标:替换掉C3P0,用druid来替换 替换原因: 1.性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 .hikariCP的高性能得益于最大限度的避免锁竞争. 2.druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性. 3.综合性能,扩展性等方面,可考虑使用druid或

  • Java中Druid连接池连接超时获取不到连接的解决

    错误内容: com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 30000, active 600, maxActive 600, creating 0 detail: Service Error:Cannot find a proper coonection from STDB 错误日志截图: 解决过程: 1.添加了三个参数 作用是如果超过3分钟,连接未释放,那么关闭连接,并报错. 2.进行请求,并查看日志 确认获

  • 详解Spring Boot下Druid连接池的使用配置分析

    引言: 在Spring Boot下默认提供了若干种可用的连接池,Druid来自于阿里系的一个开源连接池,在连接池之外,还提供了非常优秀的监控功能,这里讲解如何与Spring Boot实现集成. 1.  环境描述 spring Boot 1.4.0.RELEASE,  JDK 1.8 2.   Druid介绍 Druid是一个JDBC组件,它包括三部分: DruidDriver 代理Driver,能够提供基于Filter-Chain模式的插件体系. DruidDataSource 高效可管理的数据

  • 阿里Druid数据连接池引发的线上异常解决

    目录 前言 过程一:定位工作流 过程二:定位JPA的OpenEntityManagerInViewInterceptor 过程三:定位Druid,真正的罪魁祸首 后记: 前言 事件起因:项目使用了activiti工作流,系统是由老的spring mvc项目改造成的spring boot项目,数据库链接池从dbcp切换到druid,新系统上线后,同事多次系统隔一段时间后数据查询就很慢,基本出不来. 由此开始了线上bug排查之路.这个问题从一开始就模糊定位到数据库层面的问题,因为只有和数据相关的操作

  • Java开发druid数据连接池maven方式简易配置流程示例

    目录 1.pom.xml文件引入druid和数据库连接jar包 2.jdbc.properties配置 3.ibatis-config.xml关于mybatis的参数配置 4.spring-mybatis.xml整合文件配置 5.web.xml配置检测访问 禁止访问的ip 6.根据需要配置各类监控Spring-mvc.xml 7.可选安全的加密操作 数据库加密 8.访问方式 1.pom.xml文件引入druid和数据库连接jar包 <properties> <druid.version&

  • java == 引发的线上异常详解

    今天分享遇到的一个线上的 bug,线上代码: class Scratch { public static void main(String[] args) { JSONArray arrays = JSONUtil.parseArray("[{'type':1},{},{'type':2},{'type':2}" + ",{'name':'zhangsan'},{'type':1},{'type':1},{'type':1}]"); List<User>

  • Java实现数据连接池Druid举例

    目录 开篇 Druid的调试 参考 开篇 Druid号称是Java语言中最好的数据库连接池,并且能够提供强大的监控和扩展功能.作为日常使用较多的数据库连接组件,纯粹个人兴趣研究下理解下的实现原理. 理解一个工具组件最好的方式就是进行 debug,这里建议大家下载下参考连接中的 druid demo,修改下具体的数据库连接参数就可以直接进行调试跟踪. 之所以强调 Demo 的重要性,在于通过 demo 能够跟踪所有的执行流程,有了 Demo 剩下的事情只要花时间都能很好的梳理. Druid的调试

  • C#的通用DbHelper类(支持数据连接池)示例详解

    每次新项目的时候,都要从头去找一遍数据库工具类.这里分享一个简单实用的C#的通用DbHelper工具类,支持数据连接池. 连接池配置 <connectionStrings> <add name="dh_web" connectionString="Data Source=xxx.com;Initial Catalog=xx_db;User ID=xx;Password=**; pooling=true;max pool size=200" prov

  • j2Cache线上异常排查问题解决记录分析

    目录 问题背景 问题分析 假设问题 小心求证 问题重现 问题解决 问题后记-下面才是真正的原因 重新假设 最终解决 问题背景 开发反馈,线上有个服务在运行一段时间后,就会抛异常导致redis缓存不可用.项目使用了j2Caceh,异常是j2Cache的RedisCacheProvider抛出来的,如: Exception in thread "main" redis.clients.jedis.exceptions.JedisException: Could not get a reso

  • spring batch线上异常定位记录

    目录 前言 环境说明 排查过程 1.xxljob长连接导致 2.定位JpaPagingItemReader的问题 3.确定JpaPagingItemReader的问题 解决问题 前言 最近线上spring batch的一个问题围绕博主近两周时间,甚是扰神.具体现象为,spring batch执行中莫名其妙线程就卡住了,不往下走了.下面会详细描述整个问题的排查过程 环境说明 spring batch分区环境,共6个分片,两台实例,分别6个线程处理,由xxljob任务调度触发日切job,配置由apo

  • Moment的feature导致线上bug解决分析

    目录 bug的出现 bug排查 bug的根因 解决方案 bug的出现 这一天,本来是平平淡淡的一天,我正准备一如既往的到点下班,结果qa说线上出了个匪夷所思的bug. 表象为:用户在日期选择器选择了1964-01-01之后,自动变成了1963-12-31 我心里想:这是什么神奇bug,于是我又尝试了一下选择1964-01-02.1963-12-31.1965-01-01.1963-01-01,结果都正常,那么到底是为什么会引发这个bug呢? bug排查 由于后端把时间.日期类的字段都定义为了时间

  • ADO.NET数据连接池剖析

    本篇文章起源于在GCR MVP Open Day的时候和C# MVP张响讨论连接池的概念而来的.因此单独写一篇文章剖析一下连接池. 为什么需要连接池 剖析一个技术第一个要问的是,这项技术为什么存在. 对于每一个到SQL Server的连接,都需要经历TCP/IP协议的三次握手,身份认证,在SQL Server里建立连接,分配资源等.而当客户端关闭连接时,客户端就会和SQL Server终止物理连接.但是,我们做过数据库开发的人都知道,每次操作完后关闭连接是再正常不过的事了,一个应用程序即使在负载

  • 线上dubbo线程池耗尽CyclicBarrier线程屏障异常解决记录

    目录 事件背景 问题定位 解决问题 文末结语 事件背景 系统相关使用人员反馈系统故障,日志显示从ams系统服务提示dubbo处理线程不足,具体异常信息如下: 问题定位 从上图可知,dubbo的处理线程池满了,默认200个线程,活动线程也是200个.这个现象非常不正常,我们的应用并发还没有到这个程度能同时占用200个线程处理请求.然后去读了下dubbo源码,发现dubbo也认为这种情况不正常,然后帮我们记录了应用的线程堆栈信息,这个非常赞.代码如下: 上面这段代码,在线程池不够用时,会每隔十分钟输

随机推荐