When the number of connections to an RDS for MySQL instance reaches its maximum, all clients — including Data Management (DMS) and other tools — are refused with ERROR 1040 (HY000): Too many connections. This topic describes how to diagnose the root cause and resolve the issue.
Diagnose the problem
Run the following queries to check your current connection status:
-- Check the configured maximum connections
SELECT @@max_connections;
-- Check the number of currently connected clients
SHOW STATUS WHERE `variable_name` = 'Threads_connected';If Threads_connected is at or near max_connections, connections are exhausted.
To identify whether the issue is caused by idle or active connections, go to the Monitoring and Alerts page in the ApsaraDB RDS console and check the Session metric. Look at the mysql.active_session value to see how many sessions are active versus idle.
If most sessions are idle, see Resolve issues caused by too many idle connections.
If most sessions are active, see Resolve issues caused by too many active connections.
Resolve issues caused by too many idle connections
MySQL uses one thread per connection. Even idle connections hold a dedicated thread in the MySQL process, consuming memory and adding context-switching overhead. A large number of idle connections can exhaust the connection limit without any active workload.
Common causes of excessive idle connections include:
Persistent connection applications without a connection pool: For example, a Java application that uses persistent connections but is not configured with a connection pool. If a large initial connection count is specified at startup, the application opens many idle connections to the RDS instance immediately.
Short-lived connection applications that do not close connections: For example, a PHP application that uses short-lived connections but does not explicitly close connections after queries complete.
Step 1: Terminate idle sessions immediately
Terminate idle sessions using one of the following methods:
ApsaraDB RDS console: Go to the Session page and use session management to kill idle sessions.
DMS: Use the session management feature in DMS to identify and terminate idle sessions.
MySQL CLI: Run
kill <session_id>to terminate a specific session.
Step 2: Reduce the idle connection timeout
The RDS instance automatically terminates idle connections after a configured timeout period:
| Parameter | Default value | Description |
|---|---|---|
wait_timeout | 86,400 seconds (24 hours) | Timeout for connections in non-interactive mode |
interactive_timeout | 7,200 seconds (2 hours) | Timeout for connections in interactive mode |
The default values are long. Lowering them causes the instance to reclaim idle connections sooner. To change these parameters, go to the Parameters page in the ApsaraDB RDS console.
Changes towait_timeoutandinteractive_timeoutapply only to new connections established after the change. Existing connections retain their original timeout values.
In most cases, applications connect to RDS instances in non-interactive mode. If you want to determine the connection mode used by your application, check its connection configuration. For PHP applications, you can specify the MYSQL_CLIENT_INTERACTIVE constant in the mysql_connect() function to enable interactive mode.
Step 3: Fix connection leaks in your application
Idle connections often accumulate because the application does not explicitly close connections after completing queries. For example, PHP applications that use short-lived connections sometimes omit the connection-close step, leaving connections open until they time out.
Check your application code to make sure connections are explicitly closed after each query or operation.
Resolve issues caused by too many active connections
A large number of active connections typically indicates a performance bottleneck that is causing queries to queue up. Common causes include:
High CPU utilization
Slow queries
InnoDB lock waits or metadata lock waits
High IOPS utilization
Identify the underlying bottleneck and address it directly:
If the issue is caused by InnoDB lock waits, see What do I do if row lock waits occur on an ApsaraDB RDS for MySQL instance and the row lock waits time out?
If the issue is caused by metadata lock waits, see Use DMS to release metadata locks.
If the issue is caused by high CPU utilization, see What do I do if the CPU utilization of an ApsaraDB RDS for MySQL instance or an ApsaraDB RDS for MariaDB instance is high?
If the issue is caused by high IOPS usage, see What do I do if the IOPS usage of an ApsaraDB RDS for MySQL instance is high?
Prevent connection limit issues
Use a connection pool (recommended)
A connection pool manages a fixed set of persistent connections shared across your application, instead of opening a new connection for each request. This is the most effective long-term solution for preventing connection exhaustion, and is especially important for applications that open and close large numbers of short-lived connections — such as serverless functions or PHP applications.
When configuring the maximum pool size, set it to a value smaller than the instance's connection limit. Reserve at least 10 connections for DMS and other management operations.
For example, if your instance supports 500 connections, set the connection pool maximum to 490.
Enable connection detection and reuse
Enable connection detection in your connection pool to remove stale connections automatically. Enable the reuse feature so the pool reuses existing connections rather than opening new ones unnecessarily.
Scale up the instance type
If connection demand consistently exceeds the current limit, upgrade to a larger instance type that supports more connections.