资讯频道 → 研发管理
阅读更多

3顶
1踩

研发管理

转载新闻 解Bug之路-Druid的Bug

2017-05-16 10:58 by 副主编 jihong10102006 评论(1) 有7839人浏览
Bug Druid
笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分，所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来，写出分析思路，以飨读者，希望读者在以后的工作中能够少踩点坑。

前言

此Bug是Druid低版本的Bug,此Bug至少在1.0.12版本就已经修复。

Druid的Bug现场

在紧张的新项目开发的日子里,突然收到线上某系统的大量报警,对应系统的人员发现此系统在某一台机器上dump了大量的error日志。日志基本都是: 
Druid:  GetConnectionTimeoutException

此系统所有用到数据库的地方都抛出此异常。于是祭出重启大法，重启过后，一切Okay。然后对应的系统人员开始排查这个问题，一直没有结果。
过了两天，又收到此类型的error日志报警，而且这一次是有两台系统同时爆出此种错误。紧急重启后，将此问题紧急报到我们这边处理。鉴于本人有丰富的IO处理经验，当然落到了本人头上。

Bug复盘

此系统是通过Druid连接后面的数据库分库分表Proxy,再由此Proxy连接后面的数据库。示意图如下所示:

缩小Bug范围

获取连接超时(GetConnectionTimeoutException)此错误的出现，只有两种可能:

1.业务系统本身Druid获取连接失败。   
2.作为中间件的Sharding Proxy获取连接失败。

在这个Bug里面很明显是Druid创建连接失败，原因如下:

1.此系统有10多台机器，仅仅有两台出现此种故障。   
2.这两台重启后一切正常。

如果说这两台是由于同机房问题出现统一的网络连接异常，那么并不能解释重启后正常这一现象。

Druid问题定位

于是开始分析为何获取连接超时,第一步当然是开始寻找源码中日志抛出异常点。上源码: 
DruidConnectionHolder holder;
.......
try {
    if (maxWait > 0) {
       holder = pollLast(nanos);
    }
    else {
       holder = takeLast();
    }
    ......
}finally {
    lock.unlock();
}
if(holder == null){
   ......
    if (this.createError != null) {
        throw new GetConnectionTimeoutException(errorMessage, createError);
    } else {
        throw new GetConnectionTimeoutException(errorMessage);
    }   
}

可见，这边获取到的DruidConnectionHolder为null,则抛出异常。

Druid获取连接的过程

在分析这个问题之前，先得看下Druid是如何创建连接的,下面是本人阅读Druid源码后画的示意图:

可见druid创建连接都是通过一个专门的线程来进行的，此图省略了大量的源码细节。

为何Holde为null?

继续上源码 
private DruidConnectionHolder pollLast(long nanos) throws InterruptedException, SQLException {
    for (;;) {
        if (poolingCount == 0) {
            emptySignal(); // send signal to CreateThread create connection

            if (estimate <= 0) {
                waitNanosLocal.set(nanos - estimate);
                return null;
            }
            ...
            try {
                long startEstimate = estimate;
                estimate = notEmpty.awaitNanos(estimate); 
                ......
            } finally {
              ......
            }
            ......
            if (poolingCount == 0) {
                if (estimate > 0) {
                    continue;
                }
                waitNanosLocal.set(nanos - estimate);
                return null;
            }
        }
        decrementPoolingCount();
        DruidConnectionHolder last = connections[poolingCount];
        connections[poolingCount] = null;
        return last;
    }
}

可见，如果触发条件，estimate<=0,则返回null。
上述源码的过程示意图如下:

继续追踪

由此可见，在获取连接的时候一直超时，不停的爆GetConnectionTimeoutException异常，明显是由于创建连接线程出了问题。那到底除了什么问题呢？由于Druid的代码比较多，很难定位问题点，于是还从日志入手。

进一步挖掘日志

错误信息量最大的是最初出现错误的时间点，这是笔者多年排查错误的经验总结。由于正好有两台出错，比较其错误的共同点也能对解决问题大有裨益。
大量create connection error

当笔者和同事追查错误的源头的时候，在有大量的create connection error,奇怪的是，到了一个时间点之后，就只剩GetConnectionTimeoutException异常了。
继续分析，在出现create connection error的时候，还是有部分业务请求能够执行的。即获取到了连接。
翻了翻源码，create connection error是在创建连接线程打印的，如果这个异常没有继续打印，而同时连接也获取不到，就在很大程度上表明:

创建连接根本就是被销毁了！

错误分界点

于是开始寻找什么时候create connection error开始销毁。于是通过笔者和同事在无数的错误日志中用肉眼发现了一个不寻常的日志隐蔽在大量的错误日志间: 

Druid:create holder error


在这个错误出现之后，就再也没有了create connection error,翻了翻另一台机器的日志，页是同样的现象！

源码寻找Bug

隐隐就感觉这个日志是问题错误的关键，打出这个日志的源码为: 
创建连接线程
@Override
public void run() {
            runInternal();
}

private void runInternal() {

    for (; ; ) {
        ......
        try{
            holder = new DruidConnectionHolder(DruidDataSource.this,connection);
        }catch(SQLException ex){
            LOG.error("create connection holder error",ex);
            // 这句break就是罪魁祸首
            // 至少在1.0.12修复
            break;
        }
        ......
    }
}

这边竟然在for(;;)这个死循环中break了！！！，那么这个线程也在break后跳出了死循环从而结束了，也就是说创建连接线程被销毁了！！!如下图所示:

为何create holder error?

继续搜寻日志,发现create holder error之前，会有获取事务隔离级别的报错。那么结合源码，错误的发生如下图:

即在Druid的创建连接线程创建连接成功之后，还需要拿去数据库的holdability,isolation(隔离级别)等MetaData,在获取MetaData失败的时候，则会抛出异常，导致创建连接线程Break。
但是如果在handshake的时候就失败，那么由于Druid处理了这种异常，打印create connection error,并继续创建连接。
于是就有了在create holder error之前大量create connection error，在这之后没有了的现象。

完结了么？

Druid的Bug是弄清楚了，但是为何连接如此不稳定，有大量的创建连接异常，甚至于Druid前脚创建连接成功，后脚发送命令就失败呢？

Sharding Proxy的Bug

于是此问题又萦绕在笔者心头，在又一番不下于上述过程的努力之后，发现一个月之前上线的新版本的Sharding Proxy的内存泄露Bug导致频繁GC(并定位内存泄露点),导致了上述现象，如下图所示:

由于每次内存泄露过小，同时Sharding Proxy设置的内存过大。所以上线后过了一个月才有频繁的GC现象。之前上线后，大家观察了一周，发现没有任何异常，就不再关注。与此类似，如果DB负载过高的话，笔者推测也会触发Druid的Bug。

最后处理

笔者去翻Druid最新源码，发现此问题已经修复，紧急联系各业务线升级Druid,同时让Sharding Proxy负责人修改了最新代码并上线。
终于这次的连环Bug算是填完了。

总结

追查Bug，日志和源码是最重要的两个部分。最源头的日志信息量最大，同时要对任何不同寻常的现象都加以分析并推测，最后结合源码，才能最终找出Bug。
  • 大小: 76.6 KB
  • 大小: 237.7 KB
  • 大小: 144.8 KB
  • 大小: 42.9 KB
  • 大小: 57 KB
  • 大小: 139 KB
3
顶
1
踩
评论 共 1 条 请登录后发表评论
1 楼 西蜀石兰 2017-05-17 15:40
涨见识了哈，可能用不到这个插件，但拓展了解决bug的思路和方法

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 解Bug之路-串包Bug

    解Bug之路-串包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分，所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来，写出分析思路，以飨读者，希望读者在以后的工作中能够少踩点坑。 串包Bug...

  • 解Bug之路-主从切换”未成功”?

    解Bug之路-主从切换”未成功”?前言数据库主从切换是个非常有意思的话题。能够稳定的处理主从切换是保证业务连续性的必要条件。今天笔者就来讲讲主从切换过程中一个小小的问题。故障场景最近线上进...

  • 【转】解Bug之路-串包Bug

    笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分，所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来，写出分析思路，以飨读者，希望读者在以后的工作中能够少踩点坑。 串包Bug现场 前置故障Redis超时...

  • druid keepAlive bug踩坑

    druid 1.2.5及以下版本 连接保活bug踩坑

  • Druid核心源码解析--DruidDataSource

    } // bug fixed for dead lock, for issue #2980 DruidDriver.getInstance(); /**控制创建移除连接的锁，并且通过条件去控制一个连接的生成消费**/ // public DruidAbstractDataSource(boolean lockFair){ // lock ...

  • 解Bug之路-主从切换“未成功“?

    这让对应应用的开发百思不得其解，于是求助了笔者一探究竟。 怎么发现的 应用开发收到Cat监控告警，发现这个应用(A)中的请求在好几台机器中一直稳定失败。联想到昨晚刚做过数据库主从切换演练，于是上机器netstat -...

  • SpringBoot-Druid

    拦截器和过滤器用到了servlet,所以要注册servlet 拦截器主要拦截以/druid/开头的 最后使用localhost://8080/就可以访问监控平台。

  • druid源码解读--druid连接池init方法源码解读

    Druid连接池init方法源码解读 今日主要针对druid连接池中的Data Source核心代码中的初始化方法进行源码解读和学习。尤其针对init方法中的createAndStartCreatorThread/createAndStartDestroyThread线程进行详细的...

  • druid开发步骤（部分配置bug解决）

    1.新建Maven web_app项目，名为xxx_druid，在pom.xml中引入druid-1.2.8和mysql-connector-8.0.28以及相关依赖。 pom.xml相关依赖： &lt;dependencies&gt; &lt;dependency&gt; &lt;groupId&gt;com.alibaba&lt;...

  • druid 连接不上mysql_druid-mysql-mybatis-connection - druid 获取不到连接

    org.springframework.transaction.CannotCreateTransactionException: Could not open JDBC Connection for ... nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis ...

  • springboot下使用druid-spring-boot-starter

    Druid声称是Java语言中最好的数据库连接池。spring boot start自动装配组件，简化组件使用，所以Druid也推出了druid-spring-boot-starter。 1.pom.xmlyi

  • 多数据源切换-Druid

    * @bug [nothing] * @see [nothing] * @备注: */ public class LoadDataSource extends AbstractHibernateDao { protected final Log logger = LogFactory.getLog(getClass()); private BaseExtendDao ...

  • 记录压测时阿里druid获取数据源连接阻塞的bug

    查找到druid mysqlUtis类后发现。出现阻塞原因在于版本不匹配，低版本的driud加载的是com.mysql.jdbc.MySQLConnection，而8.0版本的mysql-connector用的是com.mysql.cj.jdbc.ConnectionImpl。升级druid到1.2以上版本...

  • 西门子S7-200SMART与V20变频器基于Modbus通讯的稳定控制及应用

    内容概要：本文详细介绍了西门子S7-200SMART PLC与V20变频器通过Modbus RTU协议进行通信的具体方法和技术要点。首先阐述了硬件连接方式，强调了正确的接线和参数设置对于稳定通信的重要性。接着深入讲解了PLC程序的设计，包括Modbus主站初始化、启停控制、频率设定以及断电自恢复等功能模块的实现。此外还分享了一些实用的经验技巧，如避免通讯冲突、处理浮点数转换等问题。最后提到该方案已在实际生产环境中成功应用，表现出良好的稳定性和可靠性。 适合人群：从事自动化控制系统集成的技术人员，特别是熟悉西门子PLC和变频器产品的工程师。 使用场景及目标：适用于需要将旧型号PLC与变频器进行高效集成的企业，在不影响原有设备的基础上提升系统的智能化水平，减少人工干预，提高生产效率。 其他说明：文中提供了大量具体的编程实例和参数配置指南，有助于读者快速掌握相关技能并应用于实际工作中。同时提醒读者注意一些常见的错误及其解决方案，帮助规避潜在的风险。

  • 西门子PLC电机控制程序：封装好的功能块助力高效工业自动化

    内容概要：本文详细介绍了西门子PLC中用于电机控制的封装功能块，涵盖正转、反转、变频控制等多种功能。通过简化底层代码，提高编程效率和系统可靠性。文章展示了如何使用功能块实现正转、反转、变频控制、模拟量处理、故障处理等功能，并结合用户自定义数据类型（UDT）和多重背景技术，实现对大量电机的高效管理。此外，还提供了具体的代码示例，帮助读者更好地理解和应用这些功能块。 适合人群：从事工业自动化领域的工程师和技术人员，尤其是那些需要频繁处理电机控制任务的人群。 使用场景及目标：适用于需要简化电机控制编程、提高系统可靠性和可维护性的工业环境。主要目标是减少重复编码的工作量，提升开发效率，确保系统稳定运行。 其他说明：文中提供的代码示例和方法不仅有助于初学者快速入门，也为有经验的工程师提供了优化现有系统的思路。通过使用这些功能块，可以在短时间内完成复杂电机控制系统的搭建和调试。

  • 腐败感知指数（CPI）数据和各种治理指标数据集

    全球腐败感知数据（2000-2023）——3000行 33个指标 关于数据集 该数据集包含3000行和33列，涵盖了2000年至2023年的腐败感知指数（CPI）数据和各种治理指标。它包括国家排名、分数和其他指标，如公共部门腐败、司法腐败、贿赂指数、商业道德、民主指数、法治、政府效率、经济指标和人类发展指数。 这些数据可用于： 腐败趋势分析 腐败对GDP、人类发展指数和治理的影响 跨国比较 数据可视化和机器学习模型 该数据集对研究人员、数据分析师、政策制定者和对研究全球腐败趋势非常有用。

  • 朔州市-平鲁区-街道行政区划_140603_Shp数据-wgs84坐标系.rar

    街道级行政区划shp矢量数据，wgs84坐标系，下载直接使用

  • 脑机接口基于贝叶斯优化的FBCCA参数自动调优系统设计与实现：EEG数据处理及优化流程详解

    内容概要：本文档详细介绍了将贝叶斯优化应用于FBCCA（滤波器组公共空间模式）参数调整的完整解决方案，包括代码实现和优化流程。首先，通过MNE库加载并预处理EEG数据，进行7-30Hz的预滤波处理，提取相关事件片段。接着，定义了FBCABayesianOptimizer类，该类包含创建动态滤波器组、获取模型参数以及定义优化目标函数的方法。其中，参数空间由离散和连续参数组成，涵盖了滤波器数量、CSP组件数、起始频率、带宽、交叠率等，并通过Optuna库进行多维搜索。优化过程中采用5折交叉验证机制，同时引入智能早停策略以提高效率。最后，提供了优化结果的可视化工具，如优化轨迹图、参数重要性图和滤波器组配置图，帮助用户更好地理解和分析优化过程。 适合人群：具有一定编程基础，尤其是对机器学习、脑电数据分析及贝叶斯优化感兴趣的科研人员和技术开发者。 使用场景及目标：①通过动态滤波器组生成算法，捕捉频段间的过渡特征；②利用混合参数空间设计，探索不同参数组合的效果；③借助高效交叉验证机制和智能早停策略，提高优化效率；④通过可视化工具，直观展示优化过程和结果。 阅读建议：此资源不仅展示了完整的代码实现，还深入探讨了FBCCA参数调整的理论基础和实际应用。建议读者在学习过程中结合理论知识与代码实践，逐步理解每个步骤的原理，并尝试调整参数以观察不同设置对优化效果的影响。同时，可根据自身硬件条件，考虑扩展建议中的GPU加速、分布式优化和在线学习等高级特性。

  • 临汾市-古县-街道行政区划_141025_Shp数据-wgs84坐标系.rar

    街道级行政区划shp矢量数据，wgs84坐标系，下载直接使用

Global site tag (gtag.js) - Google Analytics