在大多数情况下，连接池问题与连接泄漏有关。应用程序可能无法正确且一致地关闭数据库连接。当您保持连接打开时，它们将保持阻塞状态，直到. net垃圾回收器通过调用Finalize()方法为您关闭它们。

你要确保你真的关闭了连接。例如，如果.Open和Close之间的代码抛出异常，下面的代码将导致连接泄漏:

var connection = new SqlConnection(connectionString);

connection.Open();
// some code
connection.Close();                

正确的方法是这样的:

var connection = new SqlConnection(ConnectionString);

try
{
     connection.Open();
     someCall (connection);
}
finally
{
     connection.Close();                
}

or

using (SqlConnection connection = new SqlConnection(connectionString))
{
     connection.Open();
     someCall(connection);
}

当你的函数从一个类方法返回一个连接时，确保你在本地缓存它并调用它的Close方法。您将使用以下代码泄漏一个连接，例如:

var command = new OleDbCommand(someUpdateQuery, getConnection());

result = command.ExecuteNonQuery();
connection().Close(); 

第一次调用getConnection()返回的连接没有被关闭。这一行不会关闭连接，而是创建一个新的连接并尝试关闭它。

如果您使用SqlDataReader或OleDbDataReader，请关闭它们。尽管关闭连接本身似乎就能达到目的，但在使用数据读取器对象时，还是要花费额外的精力显式关闭它们。

这篇来自MSDN/SQL杂志的文章“为什么连接池溢出?”解释了很多细节，并建议了一些调试策略:

Run sp_who or sp_who2. These system stored procedures return information from the sysprocesses system table that shows the status of and information about all working processes. Generally, you'll see one server process ID (SPID) per connection. If you named your connection by using the Application Name argument in the connection string, your working connections will be easy to find. Use SQL Server Profiler with the SQLProfiler TSQL_Replay template to trace open connections. If you're familiar with Profiler, this method is easier than polling by using sp_who. Use the Performance Monitor to monitor the pools and connections. I discuss this method in a moment. Monitor performance counters in code. You can monitor the health of your connection pool and the number of established connections by using routines to extract the counters or by using the new .NET PerformanceCounter controls.

在大多数情况下，连接池问题与连接泄漏有关。应用程序可能无法正确且一致地关闭数据库连接。当您保持连接打开时，它们将保持阻塞状态，直到. net垃圾回收器通过调用Finalize()方法为您关闭它们。

你要确保你真的关闭了连接。例如，如果.Open和Close之间的代码抛出异常，下面的代码将导致连接泄漏:

var connection = new SqlConnection(connectionString);

connection.Open();
// some code
connection.Close();                

正确的方法是这样的:

var connection = new SqlConnection(ConnectionString);

try
{
     connection.Open();
     someCall (connection);
}
finally
{
     connection.Close();                
}

or

using (SqlConnection connection = new SqlConnection(connectionString))
{
     connection.Open();
     someCall(connection);
}

当你的函数从一个类方法返回一个连接时，确保你在本地缓存它并调用它的Close方法。您将使用以下代码泄漏一个连接，例如:

var command = new OleDbCommand(someUpdateQuery, getConnection());

result = command.ExecuteNonQuery();
connection().Close(); 

第一次调用getConnection()返回的连接没有被关闭。这一行不会关闭连接，而是创建一个新的连接并尝试关闭它。

如果您使用SqlDataReader或OleDbDataReader，请关闭它们。尽管关闭连接本身似乎就能达到目的，但在使用数据读取器对象时，还是要花费额外的精力显式关闭它们。

这篇来自MSDN/SQL杂志的文章“为什么连接池溢出?”解释了很多细节，并建议了一些调试策略:

Run sp_who or sp_who2. These system stored procedures return information from the sysprocesses system table that shows the status of and information about all working processes. Generally, you'll see one server process ID (SPID) per connection. If you named your connection by using the Application Name argument in the connection string, your working connections will be easy to find. Use SQL Server Profiler with the SQLProfiler TSQL_Replay template to trace open connections. If you're familiar with Profiler, this method is easier than polling by using sp_who. Use the Performance Monitor to monitor the pools and connections. I discuss this method in a moment. Monitor performance counters in code. You can monitor the health of your connection pool and the number of established connections by using routines to extract the counters or by using the new .NET PerformanceCounter controls.

当我在一个。net应用程序中使用一些第三方数据层时，我也遇到过这个问题。问题是该层没有正确地关闭连接。

我们扔掉了这个层，自己创建了一个，它总是关闭和处理连接。从那以后，我们就不会再得到错误了。

在我的情况下，我有无限循环(从一个get属性试图从数据库中获取值)，不断打开数百个Sql连接。

要重现这个问题，试试这个:

while (true)
{
    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        connection.Open();
        someCall(connection);
    }
}

除了公布的解决方案。

在处理1000页遗留代码时，每个代码都多次调用公共GetRS，这里有另一种解决问题的方法:

在现有的公共DLL中，我们添加了CommandBehavior。CloseConnection选择:

static public IDataReader GetRS(String Sql)
{
    SqlConnection dbconn = new SqlConnection(DB.GetDBConn());
    dbconn.Open();
    SqlCommand cmd = new SqlCommand(Sql, dbconn);
    return cmd.ExecuteReader(CommandBehavior.CloseConnection);   
}

然后，在每个页面中，只要关闭数据读取器，连接也会自动关闭，从而防止连接泄漏。

IDataReader rs = CommonDLL.GetRS("select * from table");
while (rs.Read())
{
    // do something
}
rs.Close();   // this also closes the connection

你也可以尝试一下，解决超时问题:

如果你没有在你的webconfig中添加httpRuntime，在<system中添加。网络>标记

<sytem.web>
     <httpRuntime maxRequestLength="20000" executionTimeout="999999"/>
</system.web>

and

像这样修改你的连接字符串;

 <add name="connstring" connectionString="Data Source=DSourceName;Initial Catalog=DBName;Integrated Security=True;Max Pool Size=50000;Pooling=True;" providerName="System.Data.SqlClient" />

最后使用

    try
    {...} 
    catch
    {...} 
    finaly
    {
     connection.close();
    }