记阿里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也提供了相应的方案,如下

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

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏灯塔大数据

干货|在选择数据库的路上,我们遇到过哪些坑?

我是 FactGem 的首席技术官 Clark Richey。FactGem 是一家小公司。 在这里我想说一说我们是怎么开始接触数据库技术的,然后我们做出了哪...

30870
来自专栏灯塔大数据

每周学点大数据 | No.4算法的分析之时间复杂度

No.4期 算法的分析之时间复杂度 小可:嗯,我觉得评价一个算法的最基本方式就是看它运行得快不快。 Mr. 王:嗯,这是重要的考量标准之一。研究算法运行得快不...

30290
来自专栏开源优测

[快学Python3]PyMySQL库

概述 本文主要讲解如何使用pymysql库进行MySQL的管理操作。 主要讲解如何使用pymysql实现增删改查动作,并附上对应的示例。 安装pymysql p...

47790
来自专栏从零开始学自动化测试

python接口自动化4-绕过验证码登录(cookie)

前言 有些登录的接口会有验证码:短信验证码,图形验证码等,这种登录的话验证码参数可以从后台获取的(或者查数据库最直接)。 获取不到也没关系,可以通过添加cook...

64350
来自专栏灯塔大数据

洞察|大数据分析专家?或许这样的人根本不存在!

因为大数据这个词过于“忽悠”,乃至于大数据分析专家也让人十分景仰而不知其真身。 说实话,什么样的人可以称为大数据分析专家可能根本没有一个标准。就像笼统的说这个人...

35250
来自专栏专知

【观点】漫谈推荐系统及数据库技术

点击上方“专知”关注获取更多AI知识! 【导读】推荐系统和数据库技术,一个是偏机器学习数据挖掘相关的应用,一个是偏系统存储相关的技术,这两者在实际中有很大的应用...

48390
来自专栏崔庆才的专栏

区块链入门教程

区块链(blockchain)是眼下的大热门,新闻媒体大量报道,宣称它将创造未来。可是,简单易懂的入门文章却很少。区块链到底是什么,有何特别之处,很少有解释。 ...

41840
来自专栏小樱的经验随笔

sqlmap注入分类

注入分法不同,种类不同,来个简单的分类: 1.get型:sqlmap -u “http://xxx.xx.xxx/xx.xxx?xx=xxx”  2.pos...

45750
来自专栏逸鹏说道

不同场景下 MySQL 的迁移方案

不同场景下 MySQL 的迁移方案 一 目录 一 目录 二 为什么要迁移 三 MySQL 迁移方案概览 四 MySQL 迁移实战 4.1 场景一 一主一从结构迁...

47580
来自专栏机器学习算法与Python学习

给Python初学者:如何用 Django 写一个36Kr

关键字全网搜索最新排名 【机器学习算法】:排名第一 【机器学习】:排名第二 【Python】:排名第三 【算法】:排名第四 首先需要说明一下,这篇教程是写给初学...

39070

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励