.NET Core 5 EF Core使用PostgreSQL连接耗尽问题排查咨询

• DbContext生命周期配置错误
  最常见的是误将EF Core的DbContext注册为单例（Singleton）生命周期，单例的DbContext会持有一个长期不释放的连接，且本身线程不安全，并发请求下会出现连接状态混乱、无法归还连接池的问题。Azure Functions场景下该问题更隐蔽：Functions的DI作用域为单次函数调用，若在静态类、单例生命周期的服务中持有Scoped的DbContext实例，会直接导致DbContext泄漏，随运行时间积累占满连接。
• 异步操作缺失await
  即使所有查询都用了ToListAsync()/FirstOrDefaultAsync()等异步方法，如果调用时没有加await关键字（比如直接将Task作为接口返回值、在fire-and-forget场景下调用异步查询），DI容器会在请求触发返回时立刻释放DbContext，但此时异步数据库操作还未完成，底层Npgsql连接的状态会被破坏，无法正常归还到连接池，最终造成连接泄漏。
• 长事务/手动连接操作未正确释放
  如果代码中存在手动开启事务（BeginTransaction()/TransactionScope）、手动调用Database.GetDbConnection().Open()获取底层连接的逻辑，一旦没有用using块包裹、异常分支遗漏事务回滚/连接释放逻辑，连接会被长期持有无法归还。尤其是在事务中嵌套了第三方接口调用、文件IO等长耗时非数据库操作时，事务会持有连接长达数秒甚至数十秒，并发下很快占满连接池。
• 连接被长时间占用而非泄漏
  比如未分页的大表查询、缺失索引导致的慢查询、数据库出现行/表锁死锁，都会导致连接被持续占用无法释放；如果连接池的Max Pool Size配置（Npgsql默认值为100）小于业务并发峰值需要的连接数，也会出现连接耗尽的假象。
• 第三方组件隐式创建连接
  项目集成的审计日志、AOP拦截、操作记录等组件，如果没有走EF Core的DbContext连接管理，而是自行实例化NpgsqlConnection做数据写入且未做释放，也会造成连接泄漏，这类问题很难通过业务代码核查发现。

• PostgreSQL内置视图：直接查询pg_stat_activity系统视图，可以看到所有当前连接的状态、持有时长、执行的SQL语句、等待事件，是最快定位问题的手段。重点关注state = 'idle in transaction'的空闲事务连接、state = 'active'且执行时长超预期的慢查询连接。
• Npgsql内置日志与事件：开启Npgsql的连接池日志，可以记录每个连接的创建、归还、销毁、等待事件，配置连接池耗尽时的回调日志，可以直接拿到泄漏时的调用栈。
• .NET官方诊断工具：使用dotnet-trace、dotnet-dump抓取运行中进程的快照，可以统计堆上存活的NpgsqlConnection实例数量，通过引用链定位是哪个组件持有了未释放的连接。
• EF Core日志：开启EF Core的敏感数据日志和命令执行日志，可以追踪每个DbContext实例的创建、释放记录，以及每个查询的执行耗时，定位慢查询和DbContext未正常释放的问题。
• Roslyn静态代码分析器：开启编译器的CS4014警告（未等待异步调用），配合EF Core自带的代码分析器，可以直接扫描出缺失await的异步调用、DbContext生命周期配置错误等基础问题。

• 第一步优先查数据库侧状态：连接耗尽时立刻查询pg_stat_activity，先区分是连接真的泄漏了，还是慢查询/长事务占满了连接，记录异常连接的SQL和客户端来源，缩小排查范围。
• 第二步核查服务注册逻辑：检查Startup/Program中AddDbContext()的生命周期配置，全项目搜索是否有静态字段存储DbContext实例、单例服务注入DbContext的代码，Azure Functions项目额外核查输入绑定是否正确配置了DbContext的作用域。
• 第三步扫异步代码问题：打开编译器的CS4014警告，编译项目找所有未await的异步方法调用，重点检查接口方法中直接返回查询Task、没有加await的写法。
• 第四步核查手动连接/事务代码：全项目搜索BeginTransaction、GetDbConnection().Open、new NpgsqlConnection关键字，检查所有涉及手动连接、事务的逻辑是否正确释放，异常分支是否有回滚逻辑。
• 第五步单接口压测定位：对核心接口逐个做并发压测，每轮压测后观察数据库连接数是否回落，找到压测后连接数持续不下降的问题接口，针对性排查代码。

• 修正DbContext生命周期：普通Web API场景保持DbContext默认的Scoped生命周期即可；Azure Functions、需要在长生命周期服务中访问数据库的场景，注入IDbContextFactory<TContext>，每次使用时通过Create()方法获取上下文，配合using块用完即释放。
• 补全异步调用规范：强制开启CS4014编译错误，所有异步数据库调用必须加await，禁止fire-and-forget场景下直接调用异步查询方法。
• 规范连接与事务写法：所有手动开启的连接、事务必须用using声明，禁止在事务内执行非数据库的长耗时操作，所有异常分支必须包含事务回滚逻辑。可以在PostgreSQL侧配置idle_in_transaction_session_timeout参数，自动杀掉空闲超时的事务连接作为兜底。
• 优化连接池与查询配置：根据业务并发量合理调整连接字符串中Max Pool Size的值，注意不要超过PostgreSQL服务端max_connections的配置上限；配置合理的Command Timeout，超时自动终止慢查询释放连接；所有大结果集查询必须分页，给高频查询加索引，减少单连接的占用时长。
• 加全局防护：在全局异常中间件中增加DbContext dispose的兜底逻辑，避免请求异常时DbContext未正常释放。

内容的提问来源于stack exchange，提问作者Learn AspNet