- Newest
- Most votes
- Most comments
Based on your description, the gaps in Database Insights data combined with a nearly exhausted connection pool strongly suggest that your database was experiencing severe connection and authentication pressure during those time periods.
When connection pools are nearly exhausted, several things can happen that would explain both the application failures and the missing Database Insights data:
Connection Exhaustion Impact:
- When all available connection slots are consumed, new connection attempts fail, which would cause your application to stop working
- Frequent opening and closing of database connections without proper pooling creates significant authentication overhead
- Idle connections that remain open consume connection slots without performing useful work, preventing legitimate application connections
Why Database Insights Shows No Data: Database Insights relies on active database connections and query activity to collect metrics. During periods of extreme connection pressure:
- The database may be spending all its resources handling connection attempts rather than executing queries
- If no queries are successfully executing due to connection exhaustion, there would be minimal or no database load to report
- The monitoring system itself may struggle to maintain its own connection to collect metrics
Recommended Actions:
- Implement connection pooling in your application layer (such as PgBouncer or RDS Proxy) to reduce connection churn
- Set the
idle_in_transaction_session_timeoutparameter to automatically close idle connections - Review your application's connection handling to ensure connections are properly closed when no longer needed
- Monitor the
DatabaseConnectionsmetric in CloudWatch to track connection usage patterns - Consider increasing
max_connectionsif your workload legitimately requires more connections, though proper pooling is usually the better solution
The fact that this occurred twice in quick succession suggests an application-side issue with connection management rather than an internal AWS problem, especially since you confirmed the database didn't restart.
Sources
Initial troubleshooting for common PostgreSQL performance issues in Aurora PostgreSQL - Amazon Aurora
Troubleshoot Aurora PostgreSQL restarts and failovers | AWS re:Post
An empty gap in Performance Insights - where data is entirely missing rather than showing a flat line at zero - indicates that the internal AWS monitoring agent running on the database instance was unable to collect or report metrics during that specific window.
This behavior is a classic symptom of severe connection pressure and resource starvation on PostgreSQL, and here is exactly why it happens:
Mechanism Behind the Data Gap
PostgreSQL operates on a process-per-connection model. When a database approaches or hits its connection limits, or experiences a sudden surge in connection requests (a "connection storm"), two main bottlenecks occur:
-
CPU Starvation: The database spends massive amounts of CPU cycles on operating system context switching, process creation, and authentication handshakes.
-
Internal Lock Contention: High connection churn causes intense contention on internal PostgreSQL locks (specifically ProcArrayLock and WALWriteLock), which heavily throttles the database engine.
With Aurora Serverless v2, while the system scales ACUs dynamically, an instantaneous surge in connection attempts can completely saturate the allocated CPU before the scaling mechanism has time to react.
Because the internal Performance Insights agent relies on getting CPU time and establishing its own lightweight internal queries to sample pg_stat_activity, it gets completely starved out during these peaks. If the agent cannot execute or report its checks, CloudWatch receives no data for those minutes, resulting in a blank space in your graph rather than a zero-line.
How to Verify and Fix
To confirm and stabilize your environment, look into the following areas:
-
Correlate with CloudWatch Metrics: Check the standard CloudWatch metrics for DatabaseConnections and CPUUtilization for those exact timestamps (15:49 and 16:00). If you see CPU utilization pinning at 100% alongside a spike in connections right where the Performance Insights graph cuts out, this confirms resource starvation.
-
Implement RDS Proxy: For Aurora Serverless workloads, putting AWS RDS Proxy between your EC2 instances and the database is highly recommended. It pools and multiplexes connections, meaning your application can scale its connections up without overloading the database with process creation and authentication overhead.
-
Tune Application-Side Pooling: Ensure your application isn't leaking connections or aggressively opening and closing them. If you cannot use RDS Proxy immediately, ensure a local pooler like PgBouncer is configured correctly, and consider lowering idle_in_transaction_session_timeout in your PostgreSQL parameters to automatically drop abandoned, resource-consuming connections.
Relevant content
- AWS OFFICIALUpdated 7 months ago
