在我的例子中还发生了另一个原因，因为使用async/await，导致了相同的错误消息:

系统。InvalidOperationException: '超时。从池中获取连接之前的超时时间。这可能是因为所有池连接都在使用中，且池大小已达到最大。”

只是对发生了什么(以及我是如何解决它的)的一个快速概述，希望这将在未来帮助其他人:

找出原因

这一切都发生在ASP中。NET Core 3.1 web项目与Dapper和SQL Server，但我认为它是独立于这种类型的项目。

首先，我有一个中心函数给我SQL连接:

internal async Task<DbConnection> GetConnection()
{
    var r = new SqlConnection(GetConnectionString());
    await r.OpenAsync().ConfigureAwait(false);
    return r;
}

我在几十个方法中使用这个函数，例如:

public async Task<List<EmployeeDbModel>> GetAll()
{
    await using var conn = await GetConnection();
    var sql = @"SELECT * FROM Employee";

    var result = await conn.QueryAsync<EmployeeDbModel>(sql);
    return result.ToList();
}

正如您所看到的，我使用的是没有花括号({，})的new using语句，因此连接的处理是在函数的末尾完成的。

尽管如此，我还是得到了关于池中没有更多可用连接的错误。

我开始调试我的应用程序，并让它在异常发生时停止。当它停止时，我首先看了一下调用堆栈窗口，但这只显示了System.Data中的某个位置。SqlClient，并不是真正的帮助我:

接下来，我看了看Tasks窗口，这是一个更好的帮助:

在“等待”或“计划”状态下，对我自己的GetConnection方法的调用确实有数千次。

当在任务窗口中双击这样的一行时，它通过调用堆栈窗口向我显示了我的代码中的相关位置。

这帮助我找到了这种行为的真正原因。它在下面的代码中(只是为了完整性):

[Route(nameof(LoadEmployees))]
public async Task<IActionResult> LoadEmployees(
    DataSourceLoadOptions loadOption)
{
    var data = await CentralDbRepository.EmployeeRepository.GetAll();

    var list =
        data.Select(async d =>
            {
                var values = await CentralDbRepository.EmployeeRepository.GetAllValuesForEmployee(d);
                return await d.ConvertToListItemViewModel(
                    values,
                    Config,
                    CentralDbRepository);
            })
            .ToListAsync();
    return Json(DataSourceLoader.Load(await list, loadOption));
}

在上面的控制器操作中，我首先调用EmployeeRepository.GetAll()从数据库表“Employee”中获得模型列表。

然后，对于每个返回的模型(即结果集的每一行)，我再次对employeerepository . getallvaluesforeemployee (d)进行数据库调用。

虽然这在性能方面非常糟糕，但在异步上下环境中，它的行为方式是占用连接池连接而不适当地释放它们。

解决方案

我通过在外部SQL查询的内部循环中删除SQL查询来解决这个问题。

这应该通过完全省略它来完成，或者如果需要，将它移动到外部SQL查询中的一个/多个lpe join，以便在一个SQL查询中获得数据库中的所有数据。

吸取的教训

不要在短时间内执行大量SQL查询，特别是在使用async/await时。

您可以通过在连接字符串中指定MinPoolSize=xyz和/或MaxPoolSize=xyz来指定最小和最大池大小。然而，这个问题的原因可能是另一回事。

在大多数情况下，连接池问题与连接泄漏有关。应用程序可能无法正确且一致地关闭数据库连接。当您保持连接打开时，它们将保持阻塞状态，直到. 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.

您需要告诉数据库服务器在卸载页面时关闭连接。

protected void Page_Unload(object sender, EventArgs e) {
    if (qryCnn != null) 
        qryCnn.Close();
}

我在AWS EC2实例上也得到了这个确切的错误日志。

因为我只是部署alpha应用程序(没有真正的用户)，所以没有出现连接泄漏，而且我向Activity Monitor和sp_who确认实际上没有到数据库的连接。

我的问题与AWS有关——更具体地说，与安全组有关。只有特定的安全组可以访问我存放数据库的RDS服务器。 我使用authorization -security-group-ingress命令添加了一个入口规则，允许使用——source-group-name参数访问RDS服务器的正确EC2实例。添加了入口规则，我可以在AWS UI上看到-但我得到了这个错误。

当我在AWS UI上手动删除并添加入口规则时，突然异常不再，应用程序正在工作。

确保您为连接池设置了正确的设置。这是非常重要的，正如我在下面的文章中解释的那样: https://medium.com/@dewanwaqas/configurations-that-significantly-improves-your-app-performance-built-using-sql-server-and-net-ed044e53b60 如果遵循该方法，您将看到应用程序的性能有了极大的改善。