Cloud SQL Proxy connection pool exhaustion and metric visibility

Because the Cloud SQL Proxy does not export internal pool gauges to Cloud Monitoring, you must monitor utilization via client-side wait metrics and OS-level TCP state. To prevent silent exhaustion, client-side pools must be sized as a fraction of the proxy's --max-connections limit, accounting for the number of application processes sharing that proxy.

Monitoring Pool Utilization

Since you cannot rely on a native proxy metric, use these two signals to detect pressure before connection refusals occur:

1. Client-Side Pressure (Leading Indicator)

Monitor the connection pool metrics of your application library. A rising number of "waiters" or "pending connections" indicates the proxy pool is full or the instance is saturated.

• Java (HikariCP): Track PendingConnections.
• Go (database/sql): Track DBStats.WaitCount and WaitDuration.
• Tomcat JDBC: Compare numActive against maxActive.

2. Proxy TCP State (Real-Time Gauge)

The proxy maintains a TCP connection to the instance for every active session in its pool. You can derive current utilization by counting established sockets from the proxy process to the instance port:

# Replace [PID] with the proxy process ID and [PORT] with the instance port
ss -tpn | grep "pid=[PID]" | grep ":[PORT]" | grep ESTAB | wc -l

Divide this count by your configured --max-connections value to get a utilization percentage. This can be scraped by a monitoring agent as a custom gauge.

Sizing Strategy

To prevent exhaustion, align your limits using a top-down approach. Assumption: This assumes a standard deployment where the proxy limit is per-instance.

Step 1: Determine Proxy Limit

Calculate the proxy's --max-connections based on the instance's global limit, leaving headroom for maintenance and other proxies:

Proxy Limit = floor((Instance Max Connections - Reserved) * Headroom Factor / Total Proxy Processes)

Step 2: Determine Client Pool Size

Divide the proxy limit among the application processes sharing that specific proxy instance:

Client Pool Max = floor((Proxy Limit * Safety Factor) / App Processes per Proxy)

Step 3: Prevent Connection Pinning

Ensure client pools do not hold idle connections indefinitely, which "pins" the proxy pool. Configure maxLifetime and idleTimeout in your client library to be shorter than the proxy's own timeouts.

Verification and Constraints

Before applying these limits, verify the following:

• Flag Syntax: Check cloud-sql-proxy --help. Depending on the version, the flag may be --max-connections (hyphen) or --max_connections (underscore).
• Reserved Slots: Ensure you have subtracted reserved connections (e.g., superuser_reserved_connections in Postgres) from the instance total.

Missing Diagnostic Detail: To provide a precise sizing formula, please specify how many application processes share a single proxy process. If this is a 1:1 sidecar deployment, the calculation simplifies significantly; if it is a shared standalone proxy, the risk of silent exhaustion is higher.