Vertx连接池问题求助：vertx_sql_queue_pending值过高如何解决？

一、vertx_sql_queue_pending 过高的原因 #

这个指标代表等待从连接池获取连接的任务队列长度，数值过高通常源于以下场景：

• 并发请求超出连接池承载：当SQL请求并发量超过连接池maxSize设置值时，新请求会进入等待队列，队列长度持续攀升。
• 连接未正确释放：代码中如果存在PgConnection未关闭、异步流程异常导致连接释放逻辑未执行，会造成连接池中的连接被长期占用，无法复用，最终耗尽所有连接，新请求只能排队等待。
• SQL执行耗时过长：慢查询（比如无索引扫描、锁等待、大结果集查询）会长期占用连接池资源，导致其他请求无法及时获取连接，只能进入等待队列。
• 连接池配置不合理：maxSize设置过小，或者waitQueueSize无限制（默认-1），会让等待队列无上限增长。

二、是否需要增加连接数？ #

不能盲目调整，需先定位根本原因：

• 如果是请求过载且SQL执行效率正常：可适当调大maxSize（比如从默认10调整到20-50，注意不要超过PostgreSQL默认最大连接数100的70%，避免数据库过载）。
• 如果是连接泄漏或慢SQL问题：增加连接数只会延缓问题爆发，甚至加重数据库负担，必须先修复连接泄漏或优化慢查询。

三、其他需要调整的资源/配置 #

• 数据库侧优化：若慢查询源于数据库性能瓶颈（CPU、内存不足，磁盘IO慢），需扩容数据库资源，或优化表结构、添加索引。
• 连接池参数调优：
  • 设置waitQueueSize上限（比如100），队列满时直接拒绝请求，避免内存溢出。
  • 调整poolCleanerInterval（默认1000ms），确保及时清理闲置连接，释放资源。
  • 配置connectTimeout，避免连接数据库时长时间等待浪费资源。
• 应用侧流量控制：若请求量远超系统承载，需添加限流、降级机制，避免过多请求涌入导致连接池和数据库过载。

四、排查步骤建议 #

1. 检查连接泄漏：监控vertx_sql_pool_connections_in_use指标，若该值长期等于maxSize，大概率存在连接泄漏。可在代码中添加连接生命周期日志，或用内存分析工具追踪未关闭的连接实例。
2. 排查慢SQL：开启PostgreSQL慢查询日志（设置log_min_duration_statement = 1000，记录耗时超1秒的SQL），定位并优化耗时查询。
3. 验证配置调整：先修复根本问题，再根据实际负载调整连接池参数，同步监控指标变化。

内容的提问来源于stack exchange，提问作者Ravi Prakash