Hasura搭配GCP Cloud Run与Cloud SQL连接超限及服务报错问题咨询

1. 现有配置合理性判断 #

现有databases.yaml配置存在严重错误，核心问题是：Hasura的pool_settings.max_connections是单实例维度的连接池上限，你当前配置为400，假设日常运行80个Cloud Run实例，理论上总连接需求可达80 * 400 = 32000，远高于Cloud SQL 500的最大连接上限，触发连接溢出报错属于必然结果。

2. 参数调整方案 #

2.1 基础参数调整（无需额外组件） #

你提到的按最大实例数均摊连接上限的思路是正确的，具体调整规则如下：

• 先预留Cloud SQL的超级用户管理连接：PostgreSQL默认预留3个连接给超级用户，可将superuser_reserved_connections调低至1，释放2个业务连接额度
• 总可用业务连接按Cloud SQL最大连接数的90%计算：500 * 0.9 = 450，留10%的缓冲空间避免突发溢出
• 单实例max_connections = 总可用业务连接 / Cloud Run最大实例数 = 450 / 150 = 3，可设为2~3区间即可
• 配套调整连接池其他参数：

  pool_settings:
    connection_lifetime: 300 # 从600调低，避免无效长连接占用资源
    idle_timeout: 60 # 从180调低，快速释放空闲连接
    max_connections: 3 # 调整后的值
    retries: 1
  

• Cloud SQL侧可上调最大连接数：4vCPU+15GB配置的PostgreSQL单连接约占10MB内存，1000个连接仅占用10GB内存，完全符合配置规格，可将max_connections从默认500上调至800，进一步提升连接缓冲空间
• Cloud Run侧调高超并发阈值：默认单实例并发数为80，可根据请求耗时情况上调至150~200，降低日常运行的实例总数，进一步减少总连接消耗

2.2 集中式连接池优化方案（推荐长期使用） #

你之前使用pgpool无效是因为配置逻辑错误，正确的部署逻辑是：

• 将pgpool部署在Cloud Run与Cloud SQL之间，作为统一的连接入口
• Hasura侧的max_connections可保留为10~20，保证单实例的请求处理能力
• pgpool侧设置总最大连接数为450，统一管控到Cloud SQL的连接总数，彻底避免连接数溢出问题

3. 验证标准 #

调整后需观测两个核心指标：

• Cloud SQL总连接数稳定低于最大连接数的90%
• Hasura实例无连接池耗尽报错，Cloud Run侧500/503错误消失

内容的提问来源于stack exchange，提问作者Stathis Ntonas