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

  • 时间:
  • 浏览:50
  • 来源:大发uu快3_uu快3app注册_大发uu快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 ,浑然不顾数据库连接池的大小(假设是5000),当填到第 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 的 实现源码 发现连接池的默认大小限制是 5000

internal const int Max_Pool_Size = 5000;

默认设置就会触发大间题,实确人太好的有有好几个 多小坑。

知道了意味着着,处里起来就很简单了,将 DbContextPool 的 poolSize 设置为小于数据库连接池的 Max_Pool_Size

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