MySQL Error 1040 Too Many Connections: Check Before Raising the Limit

The site works for a while, then requests start failing with SQLSTATE[HY000] [1040] Too many connections. Raising max_connections is an easy suggestion. It is less useful if nobody has checked why the available slots are filling up.

Error 1040 concerns opening a connection to a server at its connection limit. It is not a password failure or a missing socket. The MySQL troubleshooting page distinguishes ordinary connection capacity from administrative access. Use an authorized administrative session for the investigation and keep query text private: it may contain application or customer data.

Get a small snapshot before changing anything

SELECT VERSION(), @@hostname, @@port;
SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Threads_connected', 'Threads_running', 'Max_used_connections',
  'Connection_errors_max_connections', 'Uptime'
);

First confirm that this is the database instance used by the failing application. A proxy, container or remote database can make a perfectly healthy local instance irrelevant to the incident. Record the product and version as well; familiar SQL syntax does not make MySQL and MariaDB administration identical.

Threads_connected measures open connections. Threads_running counts threads that are not sleeping, not CPU cores in use. Max_used_connections records a peak rather than current demand. Interpret historical counters against uptime and any maintenance that reset them. The definitions are documented in the MySQL status-variable reference.

A low connection count after the incident does not disprove a spike a few minutes earlier. Keep a timestamped sample and repeat it during representative load. Avoid resetting counters just to obtain a cleaner-looking screen; that removes evidence you may need.

Who is holding the connections?

SHOW FULL PROCESSLIST;

Read the user, host, database, command and state together. Sleeping connections can be normal pool capacity waiting for reuse. They are not automatically leaks. A small application deployment holding an unexpectedly large number of long-lived sessions is a lead, not a diagnosis.

If you only see your own sessions, check your privileges before assuming the list is complete. The PROCESSLIST reference explains visibility and version-specific behavior. Performance Schema offers additional monitoring options on MySQL; do not assume a MySQL-specific table exists unchanged on MariaDB.

• One account dominates: investigate that application's worker count, pooling settings and connection release paths.
• Queries remain busy for a long time: blocking or slow execution may be keeping slots occupied. A larger limit will not remove the underlying wait.
• Several applications fail together: look for shared traffic bursts, overlapping scheduled jobs or an infrastructure incident.

Count pools across the whole deployment

A pool size of twenty sounds modest until the application has eight instances. Its potential total is then 160 connections before background workers, other websites or administration tools are considered. This is a capacity-planning example, not a measured workload; pools do not necessarily open every possible connection at once.

Increasing the number of web workers can shorten the HTTP queue while sending more concurrent work to the database. Plan the two limits together. With persistent PHP connections, do not assume that finishing an HTTP request necessarily closes the underlying database session.

If query execution is the bottleneck, the guide to reading a query plan with EXPLAIN ANALYZE is a useful next step. Remember that an execution-based analysis can itself run work on the database; choose the query and environment deliberately.

When a higher limit is justified

A controlled increase can be sensible when legitimate demand exceeds the configured capacity, connection behavior is understood and the host has enough resources. Do not budget memory using a single universal megabytes-per-connection figure. The active workload matters too. Record the old setting and its configuration source before making a change.

Use the persistence mechanism supported by your actual product and package. Do not copy a MySQL SET PERSIST recipe into MariaDB without checking compatibility. On managed hosting, coordinate server capacity with the provider and review the application's pool size at the same time. MariaDB's connection-capacity guide also emphasizes peak demand rather than only the current count.

Avoid scripts that kill every sleeping connection. An apparently idle session may retain an open transaction, and terminating it can cause application errors or rollback work. Aggressively reducing wait_timeout can also leave a pool trying to reuse connections that the server has closed. Neither action should be a blind emergency default.

Check again under real load

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Threads_connected', 'Threads_running',
  'Connection_errors_max_connections', 'Uptime'
);

Compare this sample with the earlier one over a consistent counter period. An old nonzero refusal count is not a new failure; look for increases. Verify that the application can establish fresh connections during a busy period, error 1040 no longer appears and query latency remains acceptable. If connection pressure falls but users still wait, investigate the waiting queries rather than raising the limit again.