django-db-geventpool在Heroku Dyno启动时数据库连接激增，MAX_CONNS未生效

核心疑问解答 #

1. django-db-geventpool对超出MAX_CONNS请求的处理逻辑 #

django-db-geventpool的连接池会严格遵循MAX_CONNS配置：

• 当单个worker的连接请求数超出MAX_CONNS上限时，后续请求会进入等待队列，直至有空闲连接释放后再分配，不会直接突破限制创建新连接。
• 但存在特殊场景：worker启动阶段的数据库初始化操作（如Django系统级查询）可能绕过连接池的排队逻辑，短时间内临时创建超出MAX_CONNS的连接——这是因为限流逻辑主要在请求处理阶段生效，启动时的预初始化流程不受完全限制。

2. 启动阶段连接激增的原因 #

结合你的配置和场景，启动阶段连接暴增主要源于以下几点：

• 多worker并行初始化：你设置了WEB_CONCURRENCY=17，Heroku启动dyno时会同时拉起17个Gunicorn worker。每个worker启动时都会独立执行Django初始化流程，包括数据库连接初始化、信号触发、应用预加载等操作，这些操作会并发创建数据库连接。17个worker同时执行这类操作，叠加后会瞬间产生远超单workerMAX_CONNS总和的临时连接。
• 连接池预创建机制：REUSE_CONNS=2会让每个连接池预创建2个可复用连接，加上MAX_CONNS=4的上限，每个worker启动时可能先创建2个连接，若此时还有额外的初始化查询，会继续创建连接直至达到MAX_CONNS，17个worker的并发操作直接推高总连接数。
• Django隐式启动查询：Django启动过程中会执行一些隐式数据库操作，比如检查迁移状态、加载权限模型、缓存预热等，这些操作每个worker都会独立执行，进一步增加启动阶段的连接需求。

额外说明 #

从你的排查结果来看，正常流量下连接数符合预期，说明连接池在稳定运行时能正确遵守MAX_CONNS限制，问题仅出现在启动阶段的并发初始化场景。这种情况在多worker的Gevent环境中较为常见，尤其是Heroku这类一次性启动所有worker的平台。

内容的提问来源于stack exchange，提问作者Johnny Metz