EF Core 小坑:DbContextPool 会引起数据库连接池连接耗尽

  • 时间:
  • 浏览:58
  • 来源:大发快3_快3app争霸_大发快3app争霸

DbContextPool 是 ASP.NET Core 2.1 引入的新社会形态,前会 节省创建 DbContext 实例的开销,但这样 想到其中藏着有有还有一个小坑。

最近有有有还有一个 ASP.NET Core 项目持续运行一段时间后日志中就会无缘无故出现数据库连接池达到最大连接数限制的错误:

System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
   at System.Data.Common.ADP.ExceptionWithStackTrace(Exception e)

开使英语 以为是哪个地方的代码造成 DbContext 只有正常 Dispose ,但在代码中这样 找到任何相关线索。之前 人太好 这样 某些前会 怀疑的地方,唯有 DbContextPool ,于是尝试上加 DbContextPool ,结果错误就消失了。居然是 DbContextPool 引起的,但我就纳闷的是 DbContextPool 原本而是为了节省创建 DbContext 实例的开销,为何么反而消耗更多数据库连接,而是你这俩 项目的负载很低,为何么不可能 把整个连接池都消耗殆尽呢?

今天在周会上谈了你这俩 怪问提,之前 无缘无故想到:每个 DbContext 实例前会占用有有还有一个数据库连接(SqlConnection),不启用 DbContextPool 的之前 ,请求一开使英语 ,对应 DbContext 实例就被 Dispose ,数据库连接就会被放回连接池。而使用 DbContextPool 的之前 ,请求开使英语 后 DbContext 不要被 Dispose 而是被放回 DbContextPool ,DbContext 被放回属于此人 的池中,就由于它对应的数据库连接不要被放回它所属的连接池。DbContextPool 中的每有有还有一个 DbContext 都对应有有还有一个数据库连接,DbContextPool 中每多有有还有一个 DbContext ,数据库连接池中就会少有有还有一个数据库连接。当你这俩 有有还有一个池的大小不一样且 DbContextPool 大于数据库连接池,问提就来了,DbContextPool 根据自家池(假设是128)子的大小畅快地向池中填 DbContext ,浑然不顾数据库连接池的大小(假设是100),当填到第 101 个 DbContext 时就会无缘无故出现上面的错误。

你这俩 项目中用的全部都是默认设置,是全部都是默认设置就会触发你这俩 问提呢?

查看 DbContextPool 的 实现源码 发现池的默认大小限制是 128

public static IServiceCollection AddDbContextPool<TContext>(
    [NotNull] this IServiceCollection serviceCollection,
    [NotNull] Action<DbContextOptionsBuilder> optionsAction,
    int poolSize = 128)
    where TContext : DbContext
    => AddDbContextPool<TContext, TContext>(serviceCollection, optionsAction, poolSize);

查看 SqlConnention 的 实现源码 发现连接池的默认大小限制是 100

internal const int Max_Pool_Size = 100;

默认设置就会触发问提,实人太好 在的有有还有一个小坑。

知道了由于,正确处理起来就很简单了,将 DbContextPool 的 poolSize 设置为小于数据库连接池的 Max_Pool_Size

services.AddDbContextPool<JobDb>(option =>
    option.UseSqlServer(Configuration.DbConnectionStr()), 
    poolSize: 64);