What causes the "max_user_connections" warning on WordPress frontend?

Question

I'm currently getting this error in the front-end only (not inside /wp-admin):

Warning: mysqli_real_connect(): (HY000/1203): User xxx already has more than
'max_user_connections' active connections in
/hermes/.../public_html/myhome/wp-includes/wp-db.php on line 1489

Warning: mysql_connect(): User xxx already has more than
'max_user_connections' active connections in
/hermes/.../public_html/myhome/wp-includes/wp-db.php on line 1515
Error establishing a database connection

And I'm wondering how come this appear when I'm the only visitor? I'm using WP 4.5.

I did contact the host who was kind enough to reply as below:

Currently your website is showing
'Error establishing a database
connection' because the user of the
database has exceeded the
concurrent connection limit for a
user of a database, which is 10. This
is the reason website is loads
database error. The script throws the
concurrent connection error when
number of database connections
exceed the limit set on the server. In
our shared platform, we allow
maximum of 10 concurrent
connections to a database, which is
ideal in the shared platform and it is
not possible to increase this limit.
The query limit for your website will
be reset within couple of hours so
you should be able to access the
database after couple of hours. 

There are two cases the script loads
above error, one is when there is a
high traffic to the website and
database concurrent connection hits
the limit and second case is the 
database connection is not closed in
the script, even for the moderate
traffic the script loads concurrent
connection error. To overcome this
issue, you have to close the database
connection immediately after
fetching the required content from
the database. To close the database
connection you can use
mysql_close() PHP function with
connection parameter. This will help
you to use database connection limit
efficiently. 

In other words, everything is fine at our end, it's a WP error.

Answer 1

Not WordPress related, so I am not sure if I have the right to reply in here, but still increase max_user_connections in my.cnf MySQL configuration file since you are just testing.

There are number of causes for running out of connections, the most common ones involving when the Web/App server is creating unexpectedly large numbers of connections due to a miss-configuration or some script leaking connections or creating too many connections in error.

The solution: Some people increase max_connections to some very high number so MySQL never runs out of connections.

This however can cause resource utilization problems eating memory and cause MySQL server to swap or be killed by OOM killer process or very poor performance due to high contention.

Answer 2

First you want to enable errors for $wpdb, the WP database abstraction:

$GLOBALS['wpdb']->show_errors;

Else none of your DB connections will really die and abort with an instance of \WP_Error. The default error code is a 500.

The following error comes from \wpdb::db_connect():

Error establishing a database connection

There are two cases where db_connect() comes into use:

1. Connect to the DB
2. Check if there is a connection to the database

Only the first one is allowed to bail. If the connection would die while only the check is performed, it will not die and not throw this error. Now the connection is made by \wpdb_driver::connect(), which delivers the check if the connection is enabled and available. This tells you that your actual problem really is the connection itself. You can look that up (no joke) in the following file:

# interface-wp-db-driver.php
<?php
abstract class wpdb_driver {

You better do not think about if there's any correlation about the total quality of WP core code and the deep understanding of interfaces and abstract classes here.

Right before the DB connection will be declared as "failed" and the error will get dumped out, there's one nice line:

require_once WP_CONTENT_DIR . '/db-error.php';

This means, that there is a Drop In loaded before everything dies. You can use that and start a debugging mechanism there. You have the full WP core available in there. You can start emailing yourself, logging those errors in some ELK/Kibana, Spark or whatever stack, some SaaS or even to Slack (or just to a text file). Log your errors there, log what is going on, dump routes, requests, DB connection details, whatever you think might help you.

Answer 3

Web servers are multi taskers... Assuming your theme do not try to access the DB directly (not via the WPDB class), each user connection should correspond to a life time of processing a request that WP handles.

Assuming that, you probably have slow handling of each request, in combination of several requests being handled "at once" which might happen if your theme is dynamically loading content with AJAX.

(this is basically what your hosting told you, which make sense)