北斗云数据库连接池阻塞

问题定位

 

 

 

 

 

 

 

 

 

 

二零二一年五月

 

 

 

北斗云数据库连接池阻塞问题定位

• 问题描述

    北斗云系统反应部分商户服务异常，登录不上去等。

• 问题定位

1. 查看错误日志

由于北斗云是基于Haproxy做的负载均衡部署，所以第一反应就是是否有一个节点出问题了，及时查看问题定位。查看服务进程都在，发现123上的日志刷新频率很快，但是39上的基本不动，从日志情况来看，应该是39上的服务出问题了。（我们这里还需要提升 1、服务节点出现问题我们没有告警机制 2、我们不知道具体哪个节点问题，如果节点多了呢，还要每个看日志吗）

及时处理方案，39的流量负载切换到123上，由123提供服务，先保证生产问题得以解决。然后保留现场，39服务先不动，方便问题定位。

1. 定位问题

curl 模拟调用39服务接口，发现只打印了controller入参，然后线程阻塞，无任何响应，日志也无任何报错信息。刚开始以为是java线程问题,查看代码后发现这个接口比较简单，就是根据渠道编号查询了下渠道信息，没有启用多线程。感觉线程阻塞在了数据库查询这里，重新换了个登录接口模拟调用了下，发现最后一条日志打印是卡在用户信息查询数据库之前。现在大概确定是阻塞在数据库连接这里。

1. druid配置

查看北斗云项目数据库配置，有小问题，但没发现太致命的问题

 

 

1. 线程问题定位

查看39北斗云进程和线程情况，发现线程一直阻塞叠加  top -Hp pid

服务器保留快照dump文件，线程分析。

在线分析工具

https://gceasy.io/ft-index.jsp

 

 

从这个线程阻塞的情况分析，进入

com.yuantiao.report.web.channel.ChannelController.findChannelConfigInfoByChannelId(ChannelController.java:22) 

阻塞在java.util.concurrent.locks.AbstractQueuedSynchronizer

那么这个锁的来源呢，再往下看 druid.pool

com.alibaba.druid.pool.DruidDataSource.takeLast(DruidDataSource.java:2002)

 

查看这部分源码

这里我们一直没想明白，为什么会走 takeLast? 不是配置了maxWait吗？

1. debug确认问题

DruidDataSource 断点，发现druid的max_wait配置为默认的-1,配置未生效。

    

  查看配置格式，及druid版本问题等，都未解决问题。

 

1. 问题确认

最后，在查看druid配置config源码时，发现项目有个自定义的配置。

自定义位置和实际配置位置不符，导致配置不生效。

最后取消自定义配置类，用原生配置类，重启配置生效。

• Druid连接池问题场景还原

期待下次报告。

 

参考

https://www.cnblogs.com/halberd-lee/p/11304790.html