druid下莫名其妙hold15分钟+。疑是socket timeout超时15分钟后,重建了新连接导致

原创
2019/03/04 21:44
阅读数 1.1W

背景

在应用端通过mybatis的interceptor自定义Plugin拦截Executor, 统计输出sql的执行耗时。

今天生产发生一个很奇怪的问题: 莫名其妙卡顿15分钟+,其后正常返回sql正常结果! 使用druid版本是1.0.2。。。。。

日志分析

 统计发现:

  1. 出现该情况的单量有6笔,集中在特定的2个小时之内,都是查询sql;都发生在1台应用服务器上。
  2. 在这几笔订单卡住的时间内,轮询任务触发又正常查询成功并正确处理成功!
  3. 数据库层面没有慢sql;且数据库实例的指标监控稳定,应用监控除sql耗时监控异常外,其他一切正常。
  4. 日志没有输出error

推测是否是在getConnection过程中出现了等待。但因获取连接时的日志过少找不到具体的原因!

DruidDataSource的testConnectionInternal

网上的类似问题说的原因是Druid在从连接池中获取的连接(代码详见:DruidDataSource的getConnectionDirect),在开启testWhileIdle时,如果活跃时间距离当前比较久,那么将验证该连接是否有效,无效会discardConnection并再次去pool内获取

这个过程可能被数据库层面的防火墙策略已经关闭该连接,而客户端还傻傻的发sql验证直到超时。。。。

在该测试连接的方法中有一个查询超时超时时间:validationQueryTimeout。测试中是-1, 执行的是默认时间。。。。这个默认时间没有找到!! (有找到MappedStatementConfig由SqlMapConfiguration的defaultStatementTimeout)

深入理解JDBC的超时设置

应用与数据库间的timeout层级实例:
转帖: 深入理解JDBC的超时设置

 上层的timeout依赖于下层的timeout,只有下层的timeout无误时,上层的timeout才能确保正常。eg.  当socket timeout出现问题时,上层的statement timeout和transaction timeout都将失效。
 statement timeout 无法处理网络连接失败时的超时,它能做的仅仅是限制statement的操作时间;网络连接失败时的timeout必须交由JDBC来处理;JDBC的socket timeout会受到操作系统socket timeout设置的影响。

  1. Transaction Timeout: 一般存在于框架(Spring, EJB)或应用级。spring在配置事务切面的时候可以配置timeout。

  2. Statement Timeout: 通过调用JDBC的java.sql.Statement.setQueryTimeout(int timeout) API进行设置。 以myBatis为例,statement timeout的默认值可以通过sql-map-config.xml中的defaultStatementTimeout 属性进行设置。同时,也可以设置sqlmap中select,insert,update标签的timeout属性,从而对不同sql语句的超时时间进行独立的配置。

  3. JDBC的statement timeout:  通过调用Connection的createStatement()方法创建statement来executeQuery时,会注册一个 TimerTask ->CancelTask 用来给Timer -> ConnectionImpl.getCancelTimer()来处理timeout事项:发送 "KILL QUERY” 。 代码详见: StatementImpl  ConnectionImpl

  4. JDBC的socket timeout: 

    1. 由于TCP/IP的结构原因,socket没有办法探测到网络错误,因此应用也无法主动发现数据库连接断开。如果没有设置socket timeout的话,应用在数据库返回结果前会无期限地等下去,这种连接被称为dead connection。 为了避免dead connections,socket必须要有超时配置。socket timeout可以通过JDBC设置,socket timeout能够避免应用在发生网络错误时产生无休止等待的情况,缩短服务失效的时间。不推荐使用socket timeout来限制statement的执行时长,因此socket timeout的值必须要高于statement timeout,否则,socket timeout将会先生效,这样statement timeout就变得毫无意义,也无法生效。
      eg.   jdbc:mysql://xxx.xx.xxx.xxx:3306/database?connectTimeout=60000&socketTimeout=60000

  5. 操作系统的socket timeout配置


     

番外

MySQL JDBC的queryTimeout的一个坑

在该文章中说Statement.setQueryTimeout : 如果设置的超时时间过长,在当大批量的SQL同时执行时,每一个SQL都会创建一个CancelTask对象,虽然很快执行完,且会调用CancelTask.cancel()方法,但是CancelTask方法的源代码仅仅是将自己的状态修改为:CANCELLED,而并不会直接从队列中移除这个对象, 导致OOM。 建议在cancel()后需要purge一下。

解: MySQL Connector Java 5.1.44  版本 的 StatementImpl 已经有了purge; 且 在1.8版本的JDK对Timer的cancel()也增加了移除queue内容

Timer

     public int purge() {
         int result = 0;

         synchronized(queue) {
             for (int i = queue.size(); i > 0; i--) {
                 if (queue.get(i).state == TimerTask.CANCELLED) {
                     queue.quickRemove(i);
                     result++;
                 }
             }

             if (result != 0)
                 queue.heapify();
         }

         return result;
     }
}

    public void cancel() {
        synchronized(queue) {
            thread.newTasksMayBeScheduled = false;
            queue.clear();
            queue.notify();  // In case queue was already empty.
        }
    }

类似问题

通过网上blog查找发现有相似的问题存在:

  1. https://www.oschina.net/question/1450045_2157629

  2. https://www.2cto.com/database/201505/402016.html

  3. 在issues中搜索druid的testWhileIdle问题: https://github.com/alibaba/druid/issues/1260

展开阅读全文
打赏
0
3 收藏
分享
加载中
请问最后是如何解决的呢
05/21 10:13
回复
举报
更多评论
打赏
1 评论
3 收藏
0
分享
返回顶部
顶部