Unsolveable epic MySQL crashes with Wordpress

I had this error and it plagued me for weeks. Sorry you got frustrated and switched to managed hosting. I’m posting this answer for others having the same problem.

For me it was a combination of heavy bot traffic and sub-optimal Apache configuration. What happens is amid the high bot traffic, Apache crashes, restarts automatically like it’s supposed to, but there isn’t enough memory to re-launch MySQL as well, hence the Database Connection Error.

Apache2Buddy is a quick diagnostic tool you can use to evaluate your current Apache settings given the amount of RAM you have and the size of your application and make recommendations:

$ curl -L http://apache2buddy.pl/ | perl

For me the MaxRequestWorkers (MaxClients for older Apache versions) was too high. Simply following the recommendations from Apache2Buddy and restarting Apache worked. (The file where the configuration lived was a little hard to find too. It’s at /etc/apache2/mods-available/mpm_prefork.conf).

At the beginning, I set up a stress test with JMeter, with which I was able to reproduce the error. It performed much better under the new Apache configs.

As for the bot traffic, there are a number of WordPress plugins for dealing with that. I like IP Geo Block.

I wrote an article on this as it was such a hassle. For more info on the stress test, plugins for dealing with bots, check it out here

Just signed up to say thanks to markjtalbot Thanks a ton.

I had a similar problem from some time. I want to say that in my opinion 500MB is and should be enough memory for low traffic. In the past I had almost 200 users at the same time for at least 2 hours and nothing happened. And moreover there was almost nothing cashing and with original settings.

How this it looks like. IT starts with a huge number of processes from apache that consuming a lot of memory and because of that there is 100% CPU and 100% Hard drive usage I even can’t do anything in console like restart the system. Because of that mysql crashes and here you are error establishing database connection.

When it started ?, during a lot of months nothing happened so probably it was worpdress update OR wordpress update with some plugins update. I can’t tell you now if this is because of plugins but I found jetpack and sitemap creator that using cron. I assume that broken link checker, W3 cache and few other use cron either but currently under investigation. And THIS DATABASE ERROR happens periodically.

I haven’t noticed any brute attack on xmlrpc.php but could be something missed ?. Frankly nothing in apache logs.

IT could be that there is no straight answer for that and it is complex problem that include plugins and some kernel problems like cleaning cache from memory. I done some updates described here but currently not sure if that will help me and us ;(. I will write later.

I think there should some solution wrote by administrators, answer is simple it is a common problem and happens almost everyone. So few check points with solutions would be great.

I had a similar problem from some time. I want to say that in my opinion 500MB is and should be enough memory for low traffic. In the past I had almost 200 users at the same time for at least 2 hours and nothing happened. And moreover there was almost nothing cashing and with original settings.

How this it looks like. IT starts with a huge number of processes from apache that consuming a lot of memory and because of that there is 100% CPU and 100% Hard drive usage I even can’t do anything in console like restart the system. Because of that mysql crashes and here you are error establishing database connection.

When it started ?, during a lot of months nothing happened so probably it was worpdress update OR wordpress update with some plugins update. I can’t tell you now if this is because of plugins but I found jetpack and sitemap creator that using cron. I assume that broken link checker, W3 cache and few other use cron either but currently under investigation. And THIS DATABASE ERROR happens periodically.

I haven’t noticed any brute attack on xmlrpc.php but could be something missed ?. Frankly nothing in apache logs.

IT could be that there is no straight answer for that and it is complex problem that include plugins and some kernel problems like cleaning cache from memory. I done some updates described here but currently not sure if that will help me and us ;(. I will write later.

I think there should some solution wrote by administrators, answer is simple it is a common problem and happens almost everyone. So few check points with solutions would be great.

I had a similar problem and was able to finally fix it.

Background

I tried a bunch of tutorials that recommended tuning my MySQL installation and Apache configuration with no luck.

Identifying the Problem

It turns out that my site was being subjected to a brute force attack that targeted the WordPress xmlrpc.php file. H/T @sierracircle.

In order to check for this, you should view your apache2 access logs and look for suspicious POST requests. In my case, I found a huge number of POST requests to the /xmlrpc.php file coming from the same IP address (about 2 or 3 requests per second).

cd /var/log/apache2/
cat access.log

Solution

In order to fix this, I banned the offending IP address via Iptables:

Ban IP the malicious IP address (replace example with whatever IP address you want to ban) :

iptables -A INPUT -s 46.166.139.20 -j DROP

To view blocked IP address:

iptables -L INPUT -v -n

Reference: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/

I had a similar problem and was able to finally fix it.

Background

I tried a bunch of tutorials that recommended tuning my MySQL installation and Apache configuration with no luck.

Identifying the Problem

It turns out that my site was being subjected to a brute force attack that targeted the WordPress xmlrpc.php file. H/T @sierracircle.

In order to check for this, you should view your apache2 access logs and look for suspicious POST requests. In my case, I found a huge number of POST requests to the /xmlrpc.php file coming from the same IP address (about 2 or 3 requests per second).

cd /var/log/apache2/
cat access.log

Solution

In order to fix this, I banned the offending IP address via Iptables:

Ban IP the malicious IP address (replace example with whatever IP address you want to ban) :

iptables -A INPUT -s 46.166.139.20 -j DROP

To view blocked IP address:

iptables -L INPUT -v -n

Reference: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/

I had a similar problem and was able to finally fix it.

Background

I tried a bunch of tutorials that recommended tuning my MySQL installation and Apache configuration with no luck.

Identifying the Problem

It turns out that my site was being subjected to a brute force attack that targeted the WordPress xmlrpc.php file. H/T @sierracircle.

In order to check for this, you should view your apache2 access logs and look for suspicious POST requests. In my case, I found a huge number of POST requests to the /xmlrpc.php file coming from the same IP address (about 2 or 3 requests per second).

cd /var/log/apache2/
cat access.log

Solution

In order to fix this, I banned the offending IP address via Iptables:

Ban IP the malicious IP address (replace example with whatever IP address you want to ban) :

iptables -A INPUT -s 46.166.139.20 -j DROP

To view blocked IP address:

iptables -L INPUT -v -n

Reference: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/

I had a similar problem and was able to finally fix it.

Background

I tried a bunch of tutorials that recommended tuning my MySQL installation and Apache configuration with no luck.

Identifying the Problem

It turns out that my site was being subjected to a brute force attack that targeted the WordPress xmlrpc.php file. H/T @sierracircle.

In order to check for this, you should view your apache2 access logs and look for suspicious POST requests. In my case, I found a huge number of POST requests to the /xmlrpc.php file coming from the same IP address (about 2 or 3 requests per second).

cd /var/log/apache2/
cat access.log

Solution

In order to fix this, I banned the offending IP address via Iptables:

Ban IP the malicious IP address (replace example with whatever IP address you want to ban) :

iptables -A INPUT -s 46.166.139.20 -j DROP

To view blocked IP address:

iptables -L INPUT -v -n

Reference: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/

I had a similar problem and was able to finally fix it.

Background

I tried a bunch of tutorials that recommended tuning my MySQL installation and Apache configuration with no luck.

Identifying the Problem

It turns out that my site was being subjected to a brute force attack that targeted the WordPress xmlrpc.php file. H/T @sierracircle.

In order to check for this, you should view your apache2 access logs and look for suspicious POST requests. In my case, I found a huge number of POST requests to the /xmlrpc.php file coming from the same IP address (about 2 or 3 requests per second).

cd /var/log/apache2/
cat access.log

Solution

In order to fix this, I banned the offending IP address via Iptables:

Ban IP the malicious IP address (replace example with whatever IP address you want to ban) :

iptables -A INPUT -s 46.166.139.20 -j DROP

To view blocked IP address:

iptables -L INPUT -v -n

Reference: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/

I had a similar problem and was able to finally fix it.

Background

I tried a bunch of tutorials that recommended tuning my MySQL installation and Apache configuration with no luck.

Identifying the Problem

It turns out that my site was being subjected to a brute force attack that targeted the WordPress xmlrpc.php file. H/T @sierracircle.

In order to check for this, you should view your apache2 access logs and look for suspicious POST requests. In my case, I found a huge number of POST requests to the /xmlrpc.php file coming from the same IP address (about 2 or 3 requests per second).

cd /var/log/apache2/
cat access.log

Solution

In order to fix this, I banned the offending IP address via Iptables:

Ban IP the malicious IP address (replace example with whatever IP address you want to ban) :

iptables -A INPUT -s 46.166.139.20 -j DROP

To view blocked IP address:

iptables -L INPUT -v -n

Reference: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/