Azure上.NET Web API连接PostgreSQL出现预留连接槽报错排查

一、先确认实际连接使用情况 #

• 执行PostgreSQL命令查看当前总连接数：

  SELECT count(*) FROM pg_stat_activity;
  

• 进一步分析连接状态，区分活跃/空闲连接：

  SELECT usename, state, query_start, now() - query_start AS duration FROM pg_stat_activity;
  

• 查看Azure PostgreSQL监控面板的「Active Connections」指标，确认是否存在连接数触及max_connections（50）的峰值。注意：PostgreSQL默认预留3个超级用户连接（superuser_reserved_connections参数），普通用户实际可用连接数为50-3=47。

二、检查EF Core连接管理是否规范 #

• 确认DbContext生命周期：ASP.NET Core中务必使用Scoped生命周期（默认配置），禁止将DbContext注册为Singleton，否则会导致连接长期占用不释放。
• 确保DbContext被正确释放：使用using语句包裹手动创建的DbContext；依赖注入的Scoped实例由框架自动释放，但要避免异步代码中同步阻塞（如.Result/.Wait()）导致连接持有超时。
• 排查长时间运行的查询/事务：用以下命令找出耗时过久的活跃查询，这类操作会占用连接不释放：

  SELECT query, state, now() - query_start AS duration FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC;
  

• 检查连接池配置：确认连接字符串中未禁用连接池（Pooling=false），EF Core默认启用连接池，禁用会导致每次请求创建新连接，加速耗尽。同时调整Max Pool Size，建议设置为小于普通用户可用连接数（比如40），避免连接池请求超过数据库上限。

三、排查Azure平台侧的额外连接消耗 #

• 统计非应用的连接来源：检查是否有备份工具、监控服务、开发人员客户端（如pgAdmin）等占用连接，这些都会消耗max_connections配额。
• 查看Azure PostgreSQL日志：在Azure Portal的数据库资源中，找到「服务器日志」，搜索连接相关条目，定位连接数达到上限的时间点，分析异常连接的来源和类型。

四、代码层面的潜在问题排查 #

• 异步代码是否正确使用await：同步阻塞异步查询会导致连接被长时间占用无法归还连接池。
• 批量操作优化：后台批量任务（如数据导入、批量更新）是否占用过多连接，建议分批处理，每批完成后确保DbContext/连接被释放。
• 避免N+1查询：EF Core的N+1问题会导致多次数据库请求，增加连接占用频次，可通过Include/ThenInclude或投影查询优化。

五、临时缓解与长期优化 #

• 临时调高max_connections：但需注意Azure PostgreSQL的资源限制，连接数过高会增加CPU、内存消耗，需结合实例规格调整。
• 优化连接池参数：调整连接字符串中的Connection Timeout（缩短超时时间，避免无效连接占用）、Min Pool Size（保持适量空闲连接，减少新建连接开销）。
• 数据库查询优化：添加缺失索引、简化复杂查询、拆分大事务，减少连接持有时间。

内容的提问来源于stack exchange，提问作者Łukasz Kaproń