歡迎光臨
每天分享高質量文章

EF Core 小坑:DbContextPool 會引起資料庫連接池連接耗盡

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(
    [NotNull] this IServiceCollection serviceCollection,
    [NotNull] Action optionsAction,
    int poolSize = 128)
    where TContext : DbContext
    => AddDbContextPool(serviceCollection, optionsAction, poolSize);

查看 SqlConnention 的 實現原始碼 發現連接池的預設大小限制是 100

internal const int Max_Pool_Size = 100;

預設設置就會觸發問題,實實在在的一個小坑。

知道了原因,解決起來就很簡單了,將 DbContextPool 的 poolSize 設置為小於資料庫連接池的 Max_Pool_Size

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

原文地址:https://www.cnblogs.com/dudu/p/10398225.html

赞(0)

分享創造快樂