Open waterystone opened 2 months ago
你这个看上去db操作频率很低,不然也不会连接等到15分钟超时。 直接把keepAlive设置成true,testOnBorrow也配置成true吧,参考我更新后的最新属性信息介绍和配置示例。
你这个看上去db操作频率很低,不然也不会连接等到15分钟超时。 直接把keepAlive设置成true,testOnBorrow也配置成true吧,参考我更新后的最新属性信息介绍和配置示例。
我们的QPS其实很高。按我们的如下配置,理论上,每次借用连接时,如果其空闲时间超过60S,会进行一次探测;而且每隔60S也会对空闲时间超过300S的进行关闭,这样不应该会借用到空闲900S的连接吧。不知道我这么理解对不对? timeBetweenEvictionRunsMillis: 60000 minEvictableIdleTimeMillis: 300000 testWhileIdle: true
你这个看上去db操作频率很低,不然也不会连接等到15分钟超时。 直接把keepAlive设置成true,testOnBorrow也配置成true吧,参考我更新后的最新属性信息介绍和配置示例。 https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8
我们的QPS其实很高。按我们的如下配置,理论上,每次借用连接时,如果其空闲时间超过60S,会进行一次探测;而且每隔60S也会对空闲时间超过300S的进行关闭,这样不应该会借用到空闲900S的连接吧。不知道我这么理解对不对? timeBetweenEvictionRunsMillis: 60000 minEvictableIdleTimeMillis: 300000 testWhileIdle: true 确实诡异,只能后面加点日志来分析连接的物理连接创建和保活的触发时间点了。 你可以参考我的配置先调整连接池的配置。
我也有这类问题,请问怎么解决呢,我的问题是#5920
maxActive: 100
除非每台机器配置的cpu核数很多,或者你有耗时很长的单条sql或db事务,否则用不了这么多的连接,可以找台机器netstat动态监控一下你应用创建的数据库连接数。 如果你不配keepAlive为true(默认false),testWhileIdle这个参数配成true也是不起作用的,testWhileIdle(防止空闲连接被防火墙或数据库服务器直接reset,注意,被reset的连接属于tcp底层直接断开,但客户端看这些连接的状态仍然为正常状态,但这些连接无法继续使用。)生效的前提条件是keepAlive要设为true
此类问题过一段时间就会冒出来,如果看过wiki配置说明,应该知道连接保活的前提条件是keepAlive选项设置为true
@lizongbo 建议下一个版本把keepAlive这个选项默认值改为true
@lizongbo 建议下一个版本把keepAlive这个选项默认值改为true
直接改为true会有130个单测失败,周末温少会发1.2.23,等发完版本之后再来调整
@lizongbo 大佬,设置keepAlive以后你这个问题解决了么
@lizongbo 大佬,设置keepAlive以后你这个问题解决了么
我试了,不行
@lizongbo 大佬,设置keepAlive以后你这个问题解决了么
我试了,不行
我们项目没有遇到这样的问题,参考我更新之后的wiki的配置 https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8 这里面有我们项目实际用到的配置示例,可以参考这个调整你们的配置。
请问解决了吗?我这边是每天早上9点左右就会定时出现这个问题
大佬好,我们用Druid一直偶发
CommunicationsException
,升级到最新的1.2.22仍然出现,辛苦帮看下我们哪的姿势不对,万分感谢。 dbtype:MySQL dbversion:5.7 druid verion:1.2.22配置如下:
异常信息如下: