Cloud SQL Auth Proxy Connection Pool Exhaustion: Diagnosing Intermittent Spikes

Short answer

Use Cloud Monitoring’s cloudsql.googleapis.com/instance/connection_count together with SHOW PROCESSLIST (MySQL) or pg_stat_activity (PostgreSQL) to see how many sessions the database actually sees. Compare that with the proxy’s log, which records every CONNECT and DISCONNECT. If the proxy shows a connection closed but the server still lists it, you have orphaned sessions caused by the 60‑second idle timeout. Fix the mismatch by:

• Setting --max_connections and --max_pool_size so the proxy re‑uses connections instead of opening a new one for each request.
• Aligning the proxy’s --idle_timeout (or the OS tcp_keepalive_time) with the database’s wait_timeout (MySQL) or idle_in_transaction_session_timeout (PostgreSQL).
• Enabling TCP keep‑alive with --keepalive-interval so the TCP layer keeps the socket alive and surfaces silent drops before the server timeout.

Step‑by‑step diagnostics

1. Collect server‑side counts
   

   # MySQL
   SHOW PROCESSLIST;
   # PostgreSQL
   SELECT pid, state, query FROM pg_stat_activity;
   

2. Check Cloud Monitoring
   In the Cloud Console, open the cloudsql.googleapis.com/instance/connection_count metric for the instance and look for spikes that persist beyond the 60‑second window.
3. Verify proxy logs
   If you enabled --log_level=info, the log will contain lines like:

   2026-10-12T06:00:00Z CONNECT 192.168.1.10:5432
   2026-10-12T06:00:30Z DISCONNECT 192.168.1.10:5432
   

   Compare timestamps with the server list to spot orphaned sessions.
4. Adjust idle and server timeouts
   For MySQL:

   # In your instance flags
   wait_timeout=300
   interactive_timeout=300
   

   For PostgreSQL:

   # In your instance flags
   idle_in_transaction_session_timeout=300000
   

   Set the proxy idle timeout to the same value (e.g., --idle_timeout=300). If you cannot change the server flag, set the proxy idle timeout a bit lower to force early closure.
5. Enable TCP keep‑alive
   

   cloud_sql_proxy --keepalive-interval=30s ...
   

   Also set the host OS tcp_keepalive_time to 30s. This sends a keep‑alive packet every 30 seconds, keeping the TCP connection alive and allowing the server to notice a broken socket sooner.
6. Re‑test under load
   Run a synthetic load that triggers the spike and observe the connection_count metric. It should now drop back to the baseline within the idle timeout window.

What to ask next

To fine‑tune the recommendation, could you confirm which database engine you’re using (MySQL or PostgreSQL)? The exact server‑side timeout flag differs between them.