EntityFrameworkCore在睡眠状态下留下许多连接

c#

我有一个使用 Entity Framework Core 的 .net 核心 API。数据库上下文在 startup.cs 中注册如下：

  services.AddDbContext<AppDBContext>(options =>
         options.UseSqlServer(connectionString,
         providerOptions => providerOptions.CommandTimeout(60))); 

在我设置的连接字符串中

  Pooling=true;Max Pool Size=100;Connection Timeout=300

控制器调用服务中的方法，服务又调用存储库中的 aysnc 方法以进行数据检索和处理。

如果在负载测试期间并发用户数低于 500，则一切正常。然而，超过这个数字，我开始看到很多超时过期错误。当我检查数据库时，没有死锁，但我可以看到超过 100 个处于睡眠模式的连接（API 托管在两个 kubernetes pod 上）。我在测试过程中监控了这些连接，似乎没有重用当前的睡眠连接，而是将新的连接添加到池中。我的理解是实体框架核心管理打开和关闭连接，但情况似乎并非如此。还是我错过了什么？

错误如下所示：

StatusCode":500,"Message":"Error:Timeout expired. 在从池中获取连接之前超时时间已过。这可能是因为所有池连接都在使用中并且达到了最大池大小。堆栈跟踪：

在

Microsoft.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 重试, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)n

在

Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection、DbConnectionFactory connectionFactory、TaskCompletionSource 1 retry, DbConnectionOptions userOptions)n at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource1 重试、SqlConnectionOverrides 覆盖)n 在 Microsoft.Data.SqlClient.SqlConnection.Open(SqlConnectionOverrides 覆盖)n

在 Microsoft.Data.SqlClient.SqlConnection.Open()n 在

Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenInternal（预期布尔错误）n

在

Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)n 在 Microsoft.EntityFrameworkCore.Storage.RelationalConnection.BeginTransaction(IsolationLevel isolationLevel)n ..................... ..

如何dbcontext使用的示例：

控制器调用服务类中的方法：

  var result = await _myservice.SaveUserStatusAsync(userId, status);

然后在'myservice'：

  var user = await _userRepo.GetUserAsync(userId);

  ....set user status to new value and then

  return await _userRepo.UpdateUserAsync(user);

然后在'userrepo'：

  _context.user.Update(user);
   var updated = await _context.SaveChangesAsync();
   return updated > 0;

更新：

非常感谢 Ivan Yang 慷慨地提供了赏金。尽管我仍在调查中，但通过阅读下面的所有评论和答案，我学到了很多东西。这是我迄今为止尝试过的：我将池大小增加到 200（我知道这不是解决问题的正确方法），增加了 Pod 的数量，以便 API 现在可以在 4 个 Pod 上运行并分配更多内存到每个豆荚。到目前为止的最终结果是好的：500 个错误在多达 2000 个并发用户的情况下完全消失。在尝试其他选项后，我将用我的发现更新这个问题。