最近其他团队的开发人员告知我,我们项目有个feign接口调用失败了。我查看日志发现,其原因是尝试数据库连接超时,30秒内都没有连接成功。
我首先判断可能是网络不稳定,在一定时间内连接不上数据库。我登录到服务器环境看,尝试用命令行连接数据库,结果很快库连接上了,并没有命令行等待很久才有反应。后面再尝试使用ping命令测试网络,发现网络延迟很低。根据这些东西,我判断不太可能会有30秒都连接失败。
接下来我继续查看前一天的日志,发现了一个有意思的现象,这几天都是同一时间段发生了大量的database connect timeout
现象。以我对这项目的了解度,我马上就想到了这段时间有一两个定时任务,这两个定时任务都是多线程任务,并且有量的查询和写入数据,但之前都是20分钟左右跑完数据,一般会在这此事故发生段之前就执行完。看下xxl-job的执行日志,确实是在我预先的时间就开始跑任务,但是服务应用的日志却又发现在事故发生时还有定时任务在处理中,并且也都失败了,还进行了事务回滚。
大致可以判断是因为获取数据库连接的请求太多了,导致数据库连接超时。接下来我用sql脚本show GLOBAL VARIABLES like '%connect%'
查看了下,数据库的最大总连接数、单用户最大连接数,结果如下图所示,八千多的连接上限,我想我的项目实时的连接数还不至于这么大。
不是数据库服务端的问题,就可能是数据库客户端的问题,所以我就只能去我的项目应用中去排查问题。根据应用错误日志,很快排定位到是com.zaxxer.hikari.pool.HikariPool#getConnection(long)
方法的代码片段throw createTimeoutException(startTime);
抛出的超时异常。
可以推测PoolEntry poolEntry = connectionBag.borrow(timeout, MILLISECONDS);
这行代码应该是没获取到数据库连接,poolEntry
是null
,也就是说没有从连接池借
到mysql connection
.
com.zaxxer.hikari.util.ConcurrentBag#borrow
方法的主要逻辑是:
先尝试在线程独占变量threadList
中获取未被使用的mysql connection (速度快),若失败则从多线程共享变量sharedList
获取connection(速度慢),若在失败就到同步队列handoff
中阻塞超时等待(速度最慢)。
可以看出这里没有真正去创建数据库连接,只是在从变量、队列中去取出连接,此方法只是到连接池中去拿连接、不创连接。根据方法来看,如果连接池中的对象一直都在被使用中,就只能在同步队列handoff
上阻塞等待,直到触及其超时时间线,返回一个null
给调用方。事实上也确实如此,定时任务持有大量的mysql connection
,并在一段时间内没有释放,最终导致无法从连接池获取有效的连接,实际上真正的连接Driver.connect
并未超时。
找到了事故原因,那么解决起来就比较容易了,大致有连个方向:1、增加连接池超时时间,2、增加连接池的连接数。
其实方案一,不太可靠,因为我们不知道到那些定时任务要多久才能完成业务逻辑、并释放数据库连接,并且如果一直等待连接池也会导致http接口超时。所以增加连接池的链接数是个可行的方案。我初步将连接池的最小空闲数定为32,最大连接数定位64。