我有一种情况，一个应用程序随着时间的推移，从一对应用程序服务器打开一个累积的6000 +连接到一个32位SQL2005 SP2后端，最终导致内部内存压力（卸载mem2leave区日志消息，同时崩溃的应用程序）。 我假设应用程序出现故障（没有正确closures连接）。 我已经抛出了这个应用程序的人，但他暗示，这个问题可能在于SQL服务器，因为它不会出现在类似的UAT环境。 任何build议，我可以在SQL方面做什么？ 我已经考虑增加mem2leave区域，但担心这只会延迟/掩盖真正的问题。
当应用程序服务器上运行垃圾收集器时，.NET应用程序应自行清理它。 这应该每几分钟自动运行一次。
你可以查询SQL Server，并看到这些连接仍然在SQL Server上打开？
如果你在应用程序服务器上运行netstat，你会看到所有的套接字连接都打开了吗？ （在SQL Server上使用的每个spid都将在应用程序服务器上有一个套接字连接。）
如果您确实看到应用程序服务器上正在使用的所有端口，则应用程序服务器肯定不会closures连接，因为除非请求，否则SQL不会closures连接。 .NET代码可能会期望这种情况自动发生，事实并非如此。 您的testing环境中可能没有这个问题，因为使用率要低得多，而且您可能更经常地释放到testing环境中，这会导致在IIS重新启动时closures所有端口。
这绝对听起来像一个应用程序代码问题给我。
这听起来像应用程序不使用连接池。 这可能会导致像你所描述的问题。 您可以调整操作系统的一些TCP / IP设置。 这在以下知识库文章中有所描述：
SQL Server连接池被禁用时可能必须调整的TCP / IP设置的说明
当你完成使用时，你正在closures你的连接，对吧？
也看看你的应用程序池设置。 当它回收时，连接将会下降。