The site stops, or one page stops, and the error log carries a line like this one: User «account_user» has exceeded the «max_user_connections» resource. Read quickly, it seems to say we put a ceiling on you and you hit it. On this server that ceiling does not exist. It is worth understanding where the message really comes from, because the cure is a different one.
|
One correction that saves you half an hour of searching. The engine on these servers is MariaDB 10.11.16, not MySQL Server. They are close relatives, they speak the same language, and for compatibility even the command line is still called mysql. But the error messages nearly always say «MySQL», and anyone who feeds those into a search engine ends up reading pages about a different product, with different defaults from the ones here. Search for the name of the error, not the name of the product.
|
What that number is, where there is one
Every time a page of your site talks to the database it opens a connection, does what it came to do, and closes it. On a shared machine there are two separate counts of those connections, and they get mixed up constantly.
| Setting |
What it counts |
On this server |
| max_connections |
Connections open at once across the whole server, everybody on it added together. |
151 |
| max_user_connections |
Connections open at once per database user. |
0, meaning no ceiling set |
Mind how you read that zero: here zero means no limit, not «no connections». It is the value that switches the counting off. Of all the accounts on this server, exactly one has a ceiling of its own, set for a specific case. Every other account has none.
|
So there is no point asking us to raise the limit. The limit the message names is not set for your account: there is no number there to raise. What there is, is the real cause, and it is below.
|
So where does the message come from
| 1 |
From the account’s consumption brake. These servers run CloudLinux’s MySQL Governor, which measures how much database each account is using and holds back the ones that run away with it, so that one account cannot stop the machine for everybody. What it holds back comes from the account’s plan, not from a line in the engine’s configuration. That is why the message can name a resource that, in the engine, has no ceiling at all.
|
|
| 2 |
From your own application, opening connections and never closing them. This is the commonest cause in custom code. A program that opens a connection inside a loop, or uses persistent connections without reusing them, piles up live connections that are doing nothing. Before long it holds dozens open to serve one visitor.
|
|
| 3 |
From the whole-server ceiling. Those 151 connections are shared by everybody. If you exhaust them on your own, the engine refuses the rest, and the refusal can come out worded like this. It is rare, and when it happens it is always because some account was opening connections and not closing them.
|
|
Read the pattern before you touch the code
When the error shows up tells you most of what you need. Write down the time before you do anything else.
| When it appears |
What it points at |
| Only at busy hours |
Consumption. The application is heavier than the account allows, or one page is doing far too much work. See what eats CPU on a website. |
| Always at the same exact time |
A scheduled job. Either it runs far too often, or it takes longer than its interval and a second copy starts on top of the first. See cron jobs. |
| It started after an install or an update |
It is the new code. Switch off what you installed and confirm that before looking any further. |
| With the site all but idle |
Something is connecting from outside the website: an integration, a program in your office, a bot crawling pages. |
| On every site in the account at once |
It is the account at its limit, not one site. The total is what counts, and one site may be dragging all of them down. |
What to do, in order
| 1 |
Get the exact time from the PHP error log. The message the visitor sees is a summary; the line with the time and the file is in the log. That is the difference between guessing and knowing: where the PHP error log is.
|
|
| 2 |
Look at the account’s usage around that time, on cPanel’s resource usage page. The brake itself belongs to the server and has no screen in your panel: do not go looking for one. What you have are the graphs of what the account spent, and that is where the spike shows up, with the time it happened: how to monitor your site performance in cPanel. Live, over SSH, it is watching your usage in real time.
|
|
| 3 |
Hunt for connections left open. In your own code the rule is one connection per request, opened as late as possible and closed at the end, including when the program exits on an error. A persistent connection nobody reuses is worse than a plain one.
|
|
| 4 |
Reduce the work rather than asking for more room. Queries with no index, pages with no cache and jobs running every minute are what fill an account up. Only after that does changing plan make sense.
|
|
|
Raising a ceiling has never cured a leak. If the application opens connections and does not close them, giving it more connections only postpones the same error, and meanwhile the account’s usage climbs and the site gets slower for everyone. Fix the leak first; if the plan is genuinely too small after that, then it is worth moving.
|
If what you are seeing is not this error but a blank page saying there is no database connection, that is a different list of causes: when the site says it cannot connect to the database.
|
Send us the domain and the time the error appeared, and we will look at the account’s usage at that moment.
Open a support ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $9.99/mo See plans |
Português
English
