ADO.Net 连接池已达到最大池大小
我继承了一个 .net/web 服务项目，该项目存在严重的连接对象泄漏。奇怪的是，它已经投入生产相当长一段时间了，直到最近才出现任何问题。我猜垃圾收集器通常会很快清理它们。一个客户站点的一台 Web 服务器在负载过重时开始出现连接不足的情况。
显然，解决方案是修复所有连接泄漏，但这不会很快发生。我什至无法更改连接字符串中的最大池设置，连接字符串是由应用程序动态构建的。这将需要更改代码，而这需要经历一个并不快的过程。
在代码发生更改之前，我可以在服务器上做些什么来缓解这种情况吗？
为什么只有一个位置（甚至更小的位置）会出现这个问题？如果我知道这个问题的答案，我也许能够找到一个临时的解决办法。
实际问题是否可能完全是其他问题并且导致连接池问题？例如，服务器上的负载平衡可能出现问题，或者出现问题的 Web 服务器出现问题。
I've inherited a .net/web service project that has serious connection object leaks. Oddly enough it's been in production for quite some time with no problems until recently. I guess the garbage collector cleans them up fairly quickly ordinarily. One web server at one customers site has started running out of connections when under heavy load.
Obviously the solutions is to fix all the connection leaks, but that's not going to happen quickly. I can't even change the max pool setting in the connection string, the connection string is built dynamically by the app. This would require a code change which requires going through a process which is not quick.
Is there anything I can do at the server to mitigate this until a code change can happen?
Why would this be a problem at just one location, a smaller location at that? If I knew the answer to that question I might be able to figure out a temporary work around.
Is it possible the actual problem is something else entirely and it's causing a connection pool problem? For example, perhaps the load balancing on the servers is hosed or something wrong with the web server that is having the problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
快速修复可以是增加连接字符串上的池大小。添加此属性 Max
Pool Size=1000使您的字符串看起来像 ie。这A quickfix can be to increase the Pool Size on your connection string. Add this property Max
Pool Size=1000so your string looks like ie. this如果您在 IIS 6 或更高版本中托管它（我认为），那么您可以强制应用程序池按计划进行回收。我必须使用一个不会关闭与 Oracle 数据库的连接的远程处理应用程序来完成此操作；我们将对象放入自己的应用程序池中，然后将其设置为每小时回收一次。这在我们追踪问题并发布修复程序的过程中持续了几个月。
If you are hosting this in IIS 6 or above (I think) then you can force the application pool to recycle on a scheduled basis. I had to do this with a remoting app that wasn't closing connections to an Oracle database; we put the objects into their own application pool and then set it to recycle every hour. This worked for a few months while we tracked down the issue and released a fix.
确保任务完成后关闭所有连接。
Make sure you close all the connections after your task is done.