记一次普通的数据连接调试

原创
2018/04/03 21:39
阅读数 7

因政策原因,客户的系统需要统一迁移到政务云上。其实本身迁移环境到不是什么大事,但是数据库需要去oracle,迁移至PPAS(Postgresql的修改版本,下文简称pg),从而引发了这场“普通”的数据连接的调试。

首先,在进行压力测试的时候发现错误,缓冲池获取连接超时,明显默认的缓存池太小了,于是在ConnectionString中添加了缓存池的参数, MixPoolSize=10;MaxPoolSize=100; 压测顺利通过。

随后迁移至正式库,再进行回归测试的时候发现又报了这个错误,于是再次修改缓存池,Min=50,Max=200。暂时相安无事。

但周一项目上线,出了大问题,提醒无法建立连接,随后尝试使用管理工具登录数据库,提示连接已满,明显,连接被占用光了。于是先停掉一个业务进程,进入数据库,查询发现竟然有1200个连接。

因为之前oracle的时候只需要加大连接数既可解决这个问题,于是我们第一时间想到找到数据库管理员,希望可以加大连接上限(pg的连接是写在配置文件的,不能像oracle那样使用sql修改),但数据库管理员在查找了一通之后反馈说这些连接存在的时间都很长,属于明显的程序端问题。但给我们提供了一个super的用户和清除过期链接的sql脚本,这样在连接数即将用尽时可以清理出数百个连接,使业务系统不至于崩溃。

问题又被甩了回来,我们开始分析程序中的问题。 首先是资源泄露,经过查找,我们在 ashx (asp.net的一般处理程序) 页面中发现了问题,因为我司有一个统一的基类页面可以提供数据库连接,基类页面会在页面的生命周期事件中断开/释放连接,由于 ashx 页面并没有生命周期函数,所以事实上页面继承基类页面的销毁事件并不会触发,统一使用 using 的方式重新引用连接,解决这个问题(ashx因为没有生命周期和界面,所以速度非常快,所以用来实现ajax交互还是很不错的,我司因为莫名其妙的404问题已经基本弃用asp.net mvc)。

随后,发现业务系统重启之后不进行任何操作的连接数也十分的高,在我们的系统中达到了接近一千个。开始怀疑是线程池的配置问题,但因为这个连接数无法跟任何配置对应,于是暂时没有什么思路。 随后,我们试图添加超时时间,让缓冲池的连接在时间过后自动断开。经过查询,目前我们使用的驱动EDBDataProvider2.0.2.dll 并不能识别timeout的参数,也就是并不能做到超时断开,调试一度陷入了僵局。

在中午的时候,同事的系统经常崩溃,我帮他们看了一下,发现是因为实施人员将iis的线程数配置过多导致的iis不稳定(一般建议iis进程数与cpu逻辑核心数相同即可),于是突然想到也许是iis的多线程导致了初始连接数过多的问题。

经过计算,服务器8线程+业务服务1线程=9个线程,按照min poolsize=50计算,一个用户初始就会建立450个链接,而我们系统使用数据库的两个用户,也就是初始连接数就有900 了,数据正好,看来就是这个原因了。

于是跟踪了半天数据库各用户的连接情况,在中午重新设置了用户一的min size=20,max size=200,用户二的mix size=10, max size=100 ,成功解决问题。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部