达梦连接数clnt_ip不自动释放
达梦数据库-应用会话关闭没释放导致连接超出最大会话数限制而报错
背景:数据库器重启之后,有个备机磁盘挂了导致读写分离集群起不来,修复完集群正常重启之后,应用端界面有些模块可以登录,有些无法登录,{不同子模块用户有一些不一样,对应的应用服务器也不一样)日志提示服务器模式不匹配。
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105412-1787930630.png)
1 首先想到是不是驱动问题,但之前正常,可以排除驱动包问题
2 其次,应用服务器重启(用户只是中间件服务重启),问题依旧
3 查看数据库,在登录客户端有时会提示网络通信异常,多登录几次可以成功(检查网络,用户文件打开数,数据库服务进程文件打开数都正常)
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105678-1135208159.png)
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105511-666340807.png)
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105510-1111763090.png)
4 查看实例日志,显示最大连接数限制
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105297-30488905.png)
5 查看最大会话数及语句句柄设置大小,(正常来说,1500明显是足够使用的),将max_sessions修改到5000,只是登录情况好点,有些应用模块还是登录不了
select * from v$dm_ini where para_name like 'MAX_SESSION%';
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105287-215329789.png)
6 查看应用连接情况(如下图所示25和46两个服务器都连接数明显偏大,查询也没那么多活动会话。应用会话连接数没释放)
select clnt_ip,count(*) from v$sessions group by clnt_ip;
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105501-1123485781.png)
7 将对应应用服务器重启,再查询,看是否其他服务器也会出现上千会话数,如果有将对应服务器也重启,到最后查询结果如下,登录应用操作界面,各模块都正常无报错
![](https://img2020.cnblogs.com/blog/2164568/202112/2164568-20211226190105622-1401585975.png)
这只是临时的解决方案,具体的还需要改下应用的连接池。增加自动断开的机制。
一、场景
在网络状况不是非常良好,经常会出现暂时性的拥塞或者断开的情况,而且当我们重启数据库时也会发生类似的情况。所以需要配置中间件的连接池来实现连接测试以及自动重连,通过重新配置连接池,成功解决了这个问题。下面会给出一份数据源配置参数详单和一份推荐的数据源配置项。
二、连接池配置参数
1. initialSize:连接池启动时创建的初始化连接数量 2. maxActive:连接池中可同时连接的最大的连接数 3. maxIdle:连接池中最大的空闲的连接数,超过的空闲连接将被释放,如果设置为负数表示不限(maxIdle不能设置太小,因为假如在高负载的情况下,连接的打开时间比关闭的时间快,会引起连接池中idle的个数上升超过maxIdle,而造成频繁的连接销毁和创建) 4. minIdle:连接池中最小的空闲的连接数,低于这个数量会被创建新的连接(该参数越接近maxIdle,性能越好,因为连接的创建和销毁,都是需要消耗资源的;但是不能太大,因为在机器很空闲的时候,也会创建低于minidle个数的连接) 5. maxWait:最大等待时间,当没有可用连接时,连接池等待连接释放的最大时间,超过该时间限制会抛出异常,如果设置-1表示无限等待(默认为无限,调整为60000ms,避免因线程池不够用,而导致请求被无限制挂起) 6. poolPreparedStatements:开启池的prepared(默认是false) 7. maxOpenPreparedStatements:开启池的prepared 后的同时最大连接数(默认无限制) 8. minEvictableIdleTimeMillis:连接池中连接,在时间段内一直空闲, 被逐出连接池的时间(默认为30分钟,可以适当做调整,需要和后端服务端的策略配置相关) 9. removeAbandonedTimeout:超过时间限制,回收没有用(废弃)的连接(默认为 300秒,调整为180) 10. removeAbandoned:超过removeAbandonedTimeout时间后,是否进 行没用连接(废弃)的回收(默认为false,调整为true) 11. testOnBorrow:在进行borrowObject进行处理时,对拿到的connection进行validateObject校验 12. testOnReturn:在进行returnObject对返回的connection进行validateObject校验 13. testWhileIdle:重点,GenericObjectPool中针对pool管理,起了一个Evict的TimerTask定时线程进行控制(可通过设置参数timeBetweenEvictionRunsMillis>0),定时对线程池中的链接进行validateObject校验,对无效的链接进行关闭后,会调用ensureMinIdle,适当建立链接保证最小的minIdle连接数。 14. timeBetweenEvictionRunsMillis:设置的Evict线程的时间,单位ms,大于0才会开启evict检查线程 15. validateQuery:用来做连接检查的sql 16. validateQueryTimeout:检查查询超时时间 17. numTestsPerEvictionRun:代表每次检查链接的数量,建议设置和maxActive一样大,这样每次可以有效检查所有的链接.
三、断开自动重连机制
在出现网络中断和重启数据库时,连接池中的现有连接会失效,而如果不把这些连接进行回收(销毁),当应用取到这些链接时,就会报错。那么解决办法就来了,可以得空的时候,对连接池进行检查,看他们是不是失效了。
1、主动式
设置sql validate相关参数
testWhileIdle=true //闲时检查(空闲连接)
validationQuery=select 1 //检查手段(查询)
timeBetweenEvictionRunsMillis= 30000 //多长时间检查一次
这里之所以不选择设置testOnBorrow和testOnReturn是因为这两个对性能的影响比较大,每次取链接时或者放回连接时先对连接进行验证会消耗很多资源。
当设置了testWhileIdle或者testOnBorrow/testOnReturn时必须设置validationQuery才会生效。
2、设置合理的超时时间
minEvictableIdleTimeMillis=600000(空闲链接不被回收的最长时间) //有效期
有部分资料说removeAbandoned、removeAbandonedTimeout、logAbandoned这三个参数是用来断开自动重连的。从实际测试来看removeAbandoned是用来避免某些查询长时间不能返回或者某些情况下卡会话了,由于达梦数据库是默认不设置超时自动断开的,所以根据实际情况可以在连接池设置超时自动断开。