Cloud Run上Django连接Cloud SQL的连接配额超限与连接池优化问题

结合你的场景，以下是几个经过验证的可行方案：

1. 优化数据库连接池参数 #

你当前的连接池配置会导致每个Gunicorn Worker维护独立的连接池，4个Worker的话最小连接数就达到20，直接推高活跃连接数。调整参数，让连接池规模和Worker/线程数匹配：

DATABASES = {'default': env.db()}

DATABASES['default']['OPTIONS'] = {
    'pool': {
        'min_size': 2,  # 降低最小空闲连接，减少闲置连接占用
        'max_size': 8,  # 最大连接数不超过单Worker的线程数总和
        'recycle': 300  # 每5分钟回收旧连接，避免长时间占用
    }
}

同时保留CONN_MAX_AGE配置，注意在ASGI模式下，连接复用需要和连接池配合才能生效。

2. 调整Gunicorn的并发配置 #

当前4个Worker × 8个线程 = 32个并发线程，每个线程在无连接池时会创建新的数据库连接，短时间内大量连接请求直接触发配额限制。优化配置：

WEB_CONCURRENCY=${WEB_CONCURRENCY:-2}
THREADS=${THREADS:-4}

exec /usr/local/bin/gunicorn project.asgi:application \
    --bind "0.0.0.0:$PORT" \
    --workers "$WEB_CONCURRENCY" \
    --worker-class uvicorn.workers.UvicornWorker \
    --threads "$THREADS" \
    --timeout 0

降低总并发数，减少同时发起的数据库连接请求数量。

3. 用Cloud SQL Auth Proxy实现连接池（替代pgBouncer） #

如果你部署pgBouncer遇到权限问题，可以改用Cloud SQL Auth Proxy的内置连接池功能，它不需要额外的复杂权限配置（只要你的服务账号有Cloud SQL Client角色）：

1. 在Cloud Run的容器中包含Cloud SQL Auth Proxy
2. 修改启动命令，先启动带连接池的Auth Proxy：

/cloud-sql-proxy --unix-socket /cloudsql --pool-size=16 your-instance-connection-name &

WEB_CONCURRENCY=${WEB_CONCURRENCY:-4}
THREADS=${THREADS:-8}

exec /usr/local/bin/gunicorn project.asgi:application \
    --bind "0.0.0.0:$PORT" \
    --workers "$WEB_CONCURRENCY" \
    --worker-class uvicorn.workers.UvicornWorker \
    --threads "$THREADS" \
    --timeout 0

3. 调整Django数据库配置连接Unix套接字：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': '你的数据库名',
        'USER': '你的数据库用户',
        'PASSWORD': '你的数据库密码',
        'HOST': '/cloudsql/你的实例连接名',
        'CONN_MAX_AGE': 300,
    }
}

Auth Proxy会统一管理数据库连接，避免Django侧频繁发起连接请求触发配额。

4. 申请提高Cloud SQL配额（最后手段） #

如果以上优化都无法解决，可以向Google申请提高Connect Queries per minute per user per region的配额，但这是应急方案，优先通过连接管理优化解决问题。

内容的提问来源于stack exchange，提问作者Carlos David