[alibaba/druid]1%概率出现GetConnectionTimeoutException: wait millis 5000, active 0, maxActive 60, creating 1

+1，同样的问题，也有datasourceProxy ，版本 1.2.5

通常是每台客户端的maxActive设置太大了，全部客户端加起来的active连接总数超过了数据库服务端配置的最大连接数，获取连接一直等到超时也没有等到可用的连接。

通常是每台客户端的maxActive设置太大了，全部客户端加起来的active连接总数超过了数据库服务端配置的最大连接数，获取连接一直等到超时也没有等到可用的连接。

服务端那边也问了，说是没有特别大的压力。而且客户端这边进行创建连接的时候是成功的，这个监控是有的

通常是每台客户端的maxActive设置太大了，全部客户端加起来的active连接总数超过了数据库服务端配置的最大连接数，获取连接一直等到超时也没有等到可用的连接。

在控制台看了MySQL的配置，目前最大消耗连接数4000左右，数据库支持最大连接50000个，肯定没超过数据库最大连接数。

不是数据库自己配多少就行的，操作系统的tcp配置参数是否能支持这么多，不是数据库自己就确定的，需要tcpdump抓包分析数据库连接tcp报文，不是简单执行以下top看看cpu和内存就能判定的事情。

不是数据库自己配多少就行的，操作系统的tcp配置参数是否能支持这么多，不是数据库自己就确定的，需要tcpdump抓包分析数据库连接tcp报文，不是简单执行以下top看看cpu和内存就能判定的事情。

我这边主要是监控druid建立连接的时候没有异常，而且都很快，所以应该不是你说这种情况？ @Override public ConnectionProxy connection_connect(FilterChain chain, Properties info) throws SQLException {

请问一下之前说的“filter之后没有重置filterChain的pos，filterchain只执行一次，你的filter统计值大概率只用了一次”这个问题是存在的吗？因为connect监控到的数据确实少。但我看大佬你后面编辑了，所以是不是有这个问题呢？因为连接一直很快所以很困惑. 另外我发现有陈年issue说statFilter有内存泄漏问题的，在1.2.3是不是可能碰到，如果然后connect时候我的filter没执行导致我看不到异常？

对于你说的“你应该关注那个正在执行createPhysicalConnection创建连接操作的线程为什么没有在5ms内完成创建，等了5秒也没完成创建。”，如果监控没问题的话，那就是createPhysicalConnection一直很快成功，可是却无法拿来使用。（active=0）所有的线程都在等这个连接却等不到，感觉说不通？所以如果createPhysicalConnection的filter chain是不是有问题呢？

我看了一下druid 1.2.3代码，没有filterchain执行次数的问题，所以我改了回复内容。 建议你用arthas之类的工具抓一下你的filterchain，设置一下执行超时阈值，比如1s，查一下执行慢的环节。 从你的日志内容分析，那个负责创建连接的线程执行缓慢，如果创建连接没有问题，大概率就要查一下你的filter代码了。

我看了一下druid 1.2.3代码，没有filterchain执行次数的问题，所以我改了回复内容。 建议你用arthas之类的工具抓一下你的filterchain，设置一下执行超时阈值，比如1s，查一下执行慢的环节。 从你的日志内容分析，那个负责创建连接的线程执行缓慢，如果创建连接没有问题，大概率就要查一下你的filter代码了。

这个问题最近两个月只出了2次，目前在本地没有重现。创建连接的task看起来很少日志，我全局搜了日志也没看到创建失败的，所以是不是可以认为创建就是没问题的？我的filter代码可以贴出来：

@Override
    public ConnectionProxy connection_connect(FilterChain chain, Properties info) throws SQLException {
        Transaction transaction = Cat.newTransaction(DATABASE, "connect");
        try {
            ConnectionProxy connection = chain.connection_connect(info);
            transaction.setSuccess();
            return connection;
        } catch (Throwable ex) {
            transaction.setStatus(ex);
            throw ex;
        } finally {
            transaction.complete();
        }
    }

    @Override
    public DruidPooledConnection dataSource_getConnection(FilterChain chain, DruidDataSource dataSource, long maxWaitMillis) throws SQLException {
        Transaction transaction = Cat.newTransaction(DATABASE, "getConnection");
        try {
            DruidPooledConnection conn = chain.dataSource_connect(dataSource, maxWaitMillis);
            long id = getConnectionId(conn);
            transaction.addData("id", id);
            if (id == 0L) {
                transaction.setFail();
            } else {
                transaction.setSuccess();
            }
            return conn;
        } catch (Throwable ex) {
            transaction.setStatus(ex);
            throw ex;
        } finally {
            transaction.complete();
        }

建议在Cat.newTransaction和Cat.newTransaction方法调用前后获取一下当前时间戳，计算一下方法调用的耗时，耗时超过100ms写一条告警日志吧。 也可以考虑升级一下druid版本看看，druid之前的连接池管理的确有一些缺陷。 两个月只出现两次，说明问题偶发因素很大，如果还保存有同时段的数据库服务端日志，可以查一下数据库日志，也存在数据库服务因为自身部署环境出现资源瓶颈没有及时处理请求连接的可能性。