ERROR 1040 (HY000): Too Many Connections

You tried to connect to your database and got this back.

ERROR 1040 (HY000): Too many connections

Your site might already be down when you see this, since it usually means every connection slot MySQL allows is already full. I want to walk you through the actual fix, and also the part most guides skip. Before you just raise the connection limit, you need to check your RAM first, especially on a small VPS.

Why this happens

MySQL only allows a fixed number of client connections at once. This is controlled by a setting called max_connections, and the default is 151 in most versions. That default is fine for a small site with light traffic. It runs out fast once you add a few things most solo-dev setups have. A WordPress site with several plugins each opening their own connection. A Laravel queue worker that opens a connection and never closes it. A traffic spike that briefly needs more connections than usual.

Once every slot is full, MySQL refuses new connections outright. You cannot even log in with the normal MySQL client to check what is wrong, which makes this error feel worse than it usually is.

The quick fix, without restarting MySQL

Log in with an admin account. If you already have an active session open, you can often still get in through it even while new connections are blocked.

SHOW VARIABLES LIKE 'max_connections';
SET GLOBAL max_connections = 300;

This takes effect right away, and it will get your site back online. But it does not survive a MySQL restart, since it only changes the value in memory. Treat this as a temporary patch, not the actual fix.

The permanent fix

Open your MySQL configuration file. On most Linux setups this is /etc/mysql/my.cnf or a file inside /etc/mysql/mysql.conf.d/. Add or update this line under the [mysqld] section.

[mysqld]
max_connections = 300

Then restart MySQL so the new value loads on boot.

sudo systemctl restart mysql

The catch: do the RAM math before you pick a number

Here is the part I think a lot of guides skip. Every open connection reserves memory for its own buffers, even if that connection is sitting idle. On a big dedicated database server this barely matters. On a small VPS with 1 or 2GB of RAM, it can matter a lot.

You can check your actual per-connection memory cost by running this query on your own server, instead of trusting a generic number from a blog post.

SELECT ROUND((
  @@read_buffer_size +
  @@read_rnd_buffer_size +
  @@sort_buffer_size +
  @@join_buffer_size +
  @@binlog_cache_size +
  @@thread_stack
) / 1024 / 1024, 2) AS per_connection_mb;

Multiply that number by whatever max_connections value you are considering. That gives you the worst-case memory MySQL could use just from open connections, on top of whatever you already gave InnoDB's buffer pool. If that total gets close to your VPS's total RAM, you are not fixing the problem. You are trading a connection error for an out-of-memory crash later, which is a worse failure since it can take down MySQL entirely instead of just refusing new connections.

This is the same kind of tradeoff we walked through when looking at whether Laravel Octane is worth it on a small VPS. A small server does not have spare RAM sitting around. Every setting you raise has to come from somewhere.

Find the real root cause, not just the symptom

Raising the limit treats the symptom. I would also check why you are hitting it in the first place.

SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';
SELECT user, host, command, time, state FROM information_schema.processlist WHERE command = 'Sleep' ORDER BY time DESC;

If that last query shows a large number of connections stuck in the Sleep state from the same application user, that usually means something is opening connections and never closing them. A common cause in Laravel is a queue worker or long-running script holding a connection open indefinitely. A common cause in WordPress is a plugin using persistent connections without cleaning them up.

If the real problem is a leak, raising max_connections just delays the same crash. Fixing the leak, or adding a connection pooler like ProxySQL in front of MySQL, is the actual fix for a site under real traffic.

Who should just raise the limit, and who needs to dig deeper

If this happened once during an unusual traffic spike and your processlist looks normal otherwise, raising max_connections to a value your RAM math supports is a reasonable permanent fix. If this keeps happening regularly, or your processlist shows a growing pile of Sleep connections, raising the number is just postponing the same outage. I would fix the leak first.

FAQ

Why can't I even log in to MySQL to fix this?
MySQL reserves one extra connection slot for accounts with the CONNECTION_ADMIN privilege specifically so an administrator can always get in during this exact situation. If you still cannot connect, you may need to restart MySQL as a last resort.

Is there a safe maximum value for max_connections?
There is no single safe number for every server. It depends entirely on your available RAM and your per-connection memory cost, which is why I would run the calculation on your own server rather than copying a number from a tutorial.

Does a connection pooler replace the need to set max_connections correctly?
No, but it changes what number you actually need. With a pooler like ProxySQL sitting in front of MySQL, your application can open many connections to the pooler while MySQL itself only needs a much smaller max_connections value, since the pooler reuses a small set of real connections underneath.

Will restarting MySQL fix this permanently?
Only if you also update the config file first. Restarting without changing the config just brings you back to the same default limit, and the same error, the next time connections pile up.

Could this be related to a privilege problem instead of a real connection limit?
No, this specific error is always about the connection count, not privileges. If you are dealing with a permissions issue instead, that shows a different error message, like the one we covered in our guide on the MySQL FILE privilege error.

Bottom line

This error means MySQL ran out of connection slots, and the fix is not just picking a bigger number. Check your real per-connection memory cost first, especially on a small VPS, then look at whether you are actually leaking connections before you decide raising the limit is the right call.

Sources: MySQL 8.0 Reference Manual, Server System Variables; MySQL Server Blog, Connection Handling and Scaling. Verified against official MySQL documentation on August 29, 2026.