[转帖]记druid 连接池没满,但超时问题 GetConnectionTimeoutException active 5, maxActive 100

druid,连接池,没满,超时,问题,getconnectiontimeoutexception,active,maxactive · 浏览次数 : 0

小编点评

## Druid 连接池问题分析 **问题描述:** * Druid 连接池没满,但超时问题 GetConnectionTimeoutException active 5, maxActive 100。 **异常信息:** ``` com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 6000, active 5, maxActive 100 ---- ``` **问题分析思路:** 1. **线程池满超时:** * 由于连接池没满,线程池满了,导致获取连接失败。 * 正常情况下,线程池大小应该根据需求动态调整,而不是固定为 100。 2. **单线程请求导致问题:** * 由于连接池没满,只有单线程可以成功获取连接。 * 因此,即使服务其他服务正常,但单线程请求频繁获取连接,也可能出现问题。 3. **数据库连接问题:** * 虽然日志显示数据库连接正常,但获取连接超时,也可能与数据库连接问题有关。 4. **排查方法:** * 首先排查数据库连接是否正常,确保配置和参数合理。 * 尝试增加线程池大小,或增加连接池的创建数量,直到问题解决。 * 也可以分析异常日志中其他信息,例如数据库连接状态等,进行更深入的分析。 5. **代码问题:** * 仔细分析Druid代码,查找可能导致问题的原因。 * 问题的解决可能需要修改连接池大小、线程池大小、数据库连接等配置,以及修改查询逻辑等。 **其他建议:** * 在分析问题过程中,可以记录详细的异常信息,方便后续分析和排查。 * 可以使用性能工具分析连接池的使用情况,找到优化连接池策略的途径。 * 在解决问题过程中,可以分享问题的解决方案和经验,帮助其他用户解决类似问题。

正文

记druid 连接池没满,但超时问题
GetConnectionTimeoutException active 5, maxActive 100

问题说明

线上服务突然出现报错,通过日志查找发现是因为服务升级导致压力集中到某个节点上,出现连接获取超时导致的。
从日志中也找到了异常。
异常信息:

com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 6000, active 5, maxActive 100
----
但是从这个异常信息的描述来看,跟常规的线程池满又不一样,通过异常信息来看,线程池没满(active<maxActive),但是获取连接超时,有点无头脑。

正常的应该差不多是这样:

com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 6000, active 100, maxActive 100


-----


排查思路

怀疑1
线程池满超时,可以增加线程池大小。
但是现在线程池没满,缺又出现超时,首先排查数据库是否不正常。
经过排查,数据库没有限制连接数,其它服务、客户端也能正常使用。
排除数据库问题。

怀疑2
整个环境中也只有该服务因为使用量多而出现,并发量少了之后又恢复正常。
排除锁问题(就算出现锁,也应该把线程池占满)

因为是线上环境,无法简单去更换线程池等操作,一下就陷入到僵持。
druid github上类似问题也有很多人出现,早好几年前就有人提了该问题,但直到今天也没有解决答案。


定位

在一个个浏览github上相关问题时,突然发现某一个大神指出来,通过分析源码,该问题属于BUG,是一个提示性BUG。原因解释:
    出现 GetConnectionTimeoutException 就是代表获取线程池超时,线程池满了。 
    为什么提示又说线程池没满呢( active 5, maxActive 100 )?
    这是因为异常的日志打印没有放在同步块中,使用的变量没有考虑多线程。
    简单说就是,在打印日志时,变量(active)的值已被修改,所以不是异常发生时的值。
    代码大概如下:  DruidDataSource - 1394
---    

  1.             if (holder == null) {
  2.             long waitNanos = waitNanosLocal.get();
  3.             StringBuilder buf = new StringBuilder();
  4.             buf.append("wait millis ")//
  5.                .append(waitNanos / (1000 * 1000))//
  6.                .append(", active ").append(activeCount)//
  7.                .append(", maxActive ").append(maxActive)//
  8.                .append(", creating ").append(creatingCount.get())//


            ;
---    

问题重现

1. 在查询时特意的将时间延长,造成连接池被占用
2. 在异常打印日志之前增加一点延迟(比如打个断点)


结论

本身就是因为服务中出现了一些比较复杂耗时的SQL,导致长时间占用了连接。 
但是druid打印le 会产生歧义的异常,误导了问题分析的方向,增加了复杂度。

当前使用的druid版本是1.1.5,特意去瞄了一眼最新的代码(1.2.5),该代码还是没改。

与[转帖]记druid 连接池没满,但超时问题 GetConnectionTimeoutException active 5, maxActive 100相似的内容:

[转帖]记druid 连接池没满,但超时问题 GetConnectionTimeoutException active 5, maxActive 100

记druid 连接池没满,但超时问题 GetConnectionTimeoutException active 5, maxActive 100 问题说明 线上服务突然出现报错,通过日志查找发现是因为服务升级导致压力集中到某个节点上,出现连接获取超时导致的。 从日志中也找到了异常。 异常信息: co

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次线上Oracle连接耗时过长的问题

https://www.cnblogs.com/changxy-codest/p/15670495.html 问题现象 1、远程Oracle数据库通过IP:PORT/SERVICE_NAME连接 2、应用服务通过Docker容器部署,访问Oracle联通性测试接口,需要50s左右才能返回连接成功;

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次flannel网络调整

https://www.jianshu.com/p/a772e4b951f2 背景 最近给一个子公司部署一套k8s集群,集群搭建完之后有几个新需求需要新增几个node节点,在新增节点时发现添加失败,经过查询发现是网络规划问题导致。 flannel启动失败,报错信息如下:Error registeri

[转帖]记一次使用nacos2踩到的坑

https://cloud.tencent.com/developer/article/2077110?areaSource=104001.26&traceId=7WZNP412yK3vh7ebw4th0 前言 本文素材来源朋友学习nacos2.1.1踩到的坑。直接上正菜 坑点一:出现端口被占用 因

[转帖]记一次压测引起的nginx负载均衡性能调优

https://xiaorui.cc/archives/3495 这边有个性能要求极高的api要上线,这个服务端是golang http模块实现的。在上线之前我们理所当然的要做压力测试。起初是 “小白同学” 起头进行压力测试,但当我看到那压力测试的结果时,我也是逗乐了。 现象是,直接访问Golang

[转帖]记一次使用gdb诊断gc问题全过程

https://www.cnblogs.com/codelogs/p/17092141.html 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可以发现,我们GC有

[转帖]记一次vcsa6修复过程

一、 某天发现一台vmware vCenter Server Appliance services 6偶尔能登陆了,但极不稳定,连shell都偶尔能进...... 然后利用各种手段想方设法进到shell里,这是必须的,否则白谈.... 首先查看空间:df -h,发现/和/storage/log都用了

[转帖] 记一次使用gdb诊断gc问题全过程

记一次使用gdb诊断gc问题全过程 原创:扣钉日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可