Question

Error establishing a database connection (WordPress)

  • Posted May 25, 2014

Hi there,

I’m having a really hard time figuring this out… My website shows up “Error establishing a database connection” on occasion. This happens about once a day. As soon as I reboot the droplet, the problem’s gone.

I’ve tried adding the following 2 lines in my wp-config file, as suggested on some other forums, but it didn’t work:

define(‘WP_MEMORY_LIMIT’, ‘64M’); define(‘WP_ALLOW_REPAIR’, true);

From what I read around the web, it seems that 512mb of RAM is perfectly fine for a wordpress multisite, if set correctly - though I’m having a hard time with a single (low content) site, without many plugins. I’ve also disabled/deleted the plugins that could potentially eat up a lot of memory, such as wp-backup.

If you have any suggestions for me, I’d be more than thankful! Please notice that I’m pretty new with all this, and as it’s my first time running VPS, I do have a bit hard time understanding how everything works, at the moment…

Subscribe
Share

I’ve had the same problem. Tried for weeks, went through all the suggested solutions without any success. Digital Ocean support weren’t able to help either. I’ve migrated the Wordpress to another provider now, but shortly after the migration, have had the same problem there. So my current hypothesis is that Wordpress has become very memory hungry in more recent versions, and/or there’s specific memory leaks with some common plugins. I’ve just increased memory to 2GB and swap to 2GB to see if the extra headroom fixes it.

Hi @curiousgeorge, check out our community article here or my response in the “Answers” section below.

Hi @curiousgeorge, check out our community article here or my response in the “Answers” section below.

Hi @curiousgeorge, check out our community article here or my response in the “Answers” section below.

Hey there! We have some solutions for this issue in the Answers below. Definitely check them out, especially the replies by @kamaln7 and @nestchris, as well as my own.

Hey there! We have some solutions for this issue in the Answers below. Definitely check them out, especially the replies by @kamaln7 and @nestchris, as well as my own.

The fact that DO isn’t on threads like this helping people or making public statements about something that is so clearly not working is a huge turn off. I really enjoyed using their servers for Python web apps, but I’ll be shortly migrating everything somewhere else. I’d honestly rather give my money to godaddy at this point since my sites at least worked there.

Same problem here on both of my sites!! Will be migrating my sites to another provider and closing my D.O account tomorrow.

It has happened to me on at least two occasions in the last week or so. Have to say that I hadn’t had that issue when I was with Ramnode.

We have about 20 accounts on DigitalOcean and over the past two months ALL OF THEM have been experiencing this issue, even on droplets with 4GB RAM. We’re migrating all of our sites elsewhere…


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

I Have done all of these things; spoke to support who kindly suggested it ; and i am STILL getting this issue. I am thinking about leaving DO because this is a business I am running and random error establishing a connection shouldn’t be happening, especially if I go to sleep and find out at 1AM it went down and didn’t find out until I got up at 7AM! This has been going on for now three months. I also upgraded and I STILL have the issue. Please DO , fix it, I have tried on my end and it is STILL happening. I am frustrated about it. I have opened a support ticket and sill no fix.

Can someone recommend a good Wordpress host because this is a fucking disaster.

Problem solve with this code… Very simple :)

sudo start mysql

please tired all week my site falls due this connection error will not change cloud service more

EDIT: If you’re fairly certain you’re not suffering from an xml-rpc attack, check out our article about debugging Wordpress database errors.

EDIT: We now have a community article covering xml-rpc attacks!

Hey there,

As @nestchris said, we have started seeing an influx of brute-force amplification attacks, both on our service and the rest of the internet at large. These attacks exploit the XML-RPC functionality in WordPress, as described on Securi.net

You can see if you are being taken down by this attack by running one of the following two commands on your droplet, depending on which webserver you’re running:

Apache: grep xmlrpc /var/log/apache2/access.log Nginx: grep xmlrpc /var/log/nginx/access.log

If you get any results there, it should be easy to fix this issue. If you’ve spun up a WordPress One-Click install droplet since Dec 2015, there’s a small config file which you can enable to block such attacks. We don’t enable it by default because it breaks some commonly used plugins (like Jetpack). Here are the commands you can run:

sudo a2enconf block-xmlrpc
sudo service apache2 restart

Alternatively, Jetpack has functionality to block these requests without impacting other plugins. Check out their Protect module.

If you’re running a WordPress droplet older than Dec 2015 and you don’t want to use the Jetpack plugin from Automattic, you’ll need to configure the droplet manually to block requests to xmlrpc.php:

Apache2 (goes inside your VirtualHost config):

<files xmlrpc.php> 
order allow,deny 
deny from all 
</files>

Nginx (goes inside your server{} block):

location /xmlrpc.php { 
deny all; 
}

Alternatively, if you are not having this issue due to an XML-RPC brute force attack, your Droplet might not have enough memory to deal with your traffic reliably. We recommend users run WordPress on a 1GB droplet or larger.

In order to help reduce your memory usage, you’d first want to check for any plugins using a large amount of memory. There are a lot of memory hungry plugins out there! You may also want to optimize your configuration files.

Below are some great resources that we commonly recommend in support tickets, explaining how to do so, depending on your setup:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

If none of this works, you may have no choice but to resize to a larger sized droplet that can handle your traffic.

Best, Eris Platform Support Specialist

EDIT: If you’re fairly certain you’re not suffering from an xml-rpc attack, check out our article about debugging Wordpress database errors.

EDIT: We now have a community article covering xml-rpc attacks!

Hey there,

As @nestchris said, we have started seeing an influx of brute-force amplification attacks, both on our service and the rest of the internet at large. These attacks exploit the XML-RPC functionality in WordPress, as described on Securi.net

You can see if you are being taken down by this attack by running one of the following two commands on your droplet, depending on which webserver you’re running:

Apache: grep xmlrpc /var/log/apache2/access.log Nginx: grep xmlrpc /var/log/nginx/access.log

If you get any results there, it should be easy to fix this issue. If you’ve spun up a WordPress One-Click install droplet since Dec 2015, there’s a small config file which you can enable to block such attacks. We don’t enable it by default because it breaks some commonly used plugins (like Jetpack). Here are the commands you can run:

sudo a2enconf block-xmlrpc
sudo service apache2 restart

Alternatively, Jetpack has functionality to block these requests without impacting other plugins. Check out their Protect module.

If you’re running a WordPress droplet older than Dec 2015 and you don’t want to use the Jetpack plugin from Automattic, you’ll need to configure the droplet manually to block requests to xmlrpc.php:

Apache2 (goes inside your VirtualHost config):

<files xmlrpc.php> 
order allow,deny 
deny from all 
</files>

Nginx (goes inside your server{} block):

location /xmlrpc.php { 
deny all; 
}

Alternatively, if you are not having this issue due to an XML-RPC brute force attack, your Droplet might not have enough memory to deal with your traffic reliably. We recommend users run WordPress on a 1GB droplet or larger.

In order to help reduce your memory usage, you’d first want to check for any plugins using a large amount of memory. There are a lot of memory hungry plugins out there! You may also want to optimize your configuration files.

Below are some great resources that we commonly recommend in support tickets, explaining how to do so, depending on your setup:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

If none of this works, you may have no choice but to resize to a larger sized droplet that can handle your traffic.

Best, Eris Platform Support Specialist

EDIT: If you’re fairly certain you’re not suffering from an xml-rpc attack, check out our article about debugging Wordpress database errors.

EDIT: We now have a community article covering xml-rpc attacks!

Hey there,

As @nestchris said, we have started seeing an influx of brute-force amplification attacks, both on our service and the rest of the internet at large. These attacks exploit the XML-RPC functionality in WordPress, as described on Securi.net

You can see if you are being taken down by this attack by running one of the following two commands on your droplet, depending on which webserver you’re running:

Apache: grep xmlrpc /var/log/apache2/access.log Nginx: grep xmlrpc /var/log/nginx/access.log

If you get any results there, it should be easy to fix this issue. If you’ve spun up a WordPress One-Click install droplet since Dec 2015, there’s a small config file which you can enable to block such attacks. We don’t enable it by default because it breaks some commonly used plugins (like Jetpack). Here are the commands you can run:

sudo a2enconf block-xmlrpc
sudo service apache2 restart

Alternatively, Jetpack has functionality to block these requests without impacting other plugins. Check out their Protect module.

If you’re running a WordPress droplet older than Dec 2015 and you don’t want to use the Jetpack plugin from Automattic, you’ll need to configure the droplet manually to block requests to xmlrpc.php:

Apache2 (goes inside your VirtualHost config):

<files xmlrpc.php> 
order allow,deny 
deny from all 
</files>

Nginx (goes inside your server{} block):

location /xmlrpc.php { 
deny all; 
}

Alternatively, if you are not having this issue due to an XML-RPC brute force attack, your Droplet might not have enough memory to deal with your traffic reliably. We recommend users run WordPress on a 1GB droplet or larger.

In order to help reduce your memory usage, you’d first want to check for any plugins using a large amount of memory. There are a lot of memory hungry plugins out there! You may also want to optimize your configuration files.

Below are some great resources that we commonly recommend in support tickets, explaining how to do so, depending on your setup:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

If none of this works, you may have no choice but to resize to a larger sized droplet that can handle your traffic.

Best, Eris Platform Support Specialist

EDIT: If you’re fairly certain you’re not suffering from an xml-rpc attack, check out our article about debugging Wordpress database errors.

EDIT: We now have a community article covering xml-rpc attacks!

Hey there,

As @nestchris said, we have started seeing an influx of brute-force amplification attacks, both on our service and the rest of the internet at large. These attacks exploit the XML-RPC functionality in WordPress, as described on Securi.net

You can see if you are being taken down by this attack by running one of the following two commands on your droplet, depending on which webserver you’re running:

Apache: grep xmlrpc /var/log/apache2/access.log Nginx: grep xmlrpc /var/log/nginx/access.log

If you get any results there, it should be easy to fix this issue. If you’ve spun up a WordPress One-Click install droplet since Dec 2015, there’s a small config file which you can enable to block such attacks. We don’t enable it by default because it breaks some commonly used plugins (like Jetpack). Here are the commands you can run:

sudo a2enconf block-xmlrpc
sudo service apache2 restart

Alternatively, Jetpack has functionality to block these requests without impacting other plugins. Check out their Protect module.

If you’re running a WordPress droplet older than Dec 2015 and you don’t want to use the Jetpack plugin from Automattic, you’ll need to configure the droplet manually to block requests to xmlrpc.php:

Apache2 (goes inside your VirtualHost config):

<files xmlrpc.php> 
order allow,deny 
deny from all 
</files>

Nginx (goes inside your server{} block):

location /xmlrpc.php { 
deny all; 
}

Alternatively, if you are not having this issue due to an XML-RPC brute force attack, your Droplet might not have enough memory to deal with your traffic reliably. We recommend users run WordPress on a 1GB droplet or larger.

In order to help reduce your memory usage, you’d first want to check for any plugins using a large amount of memory. There are a lot of memory hungry plugins out there! You may also want to optimize your configuration files.

Below are some great resources that we commonly recommend in support tickets, explaining how to do so, depending on your setup:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

If none of this works, you may have no choice but to resize to a larger sized droplet that can handle your traffic.

Best, Eris Platform Support Specialist

EDIT: If you’re fairly certain you’re not suffering from an xml-rpc attack, check out our article about debugging Wordpress database errors.

EDIT: We now have a community article covering xml-rpc attacks!

Hey there,

As @nestchris said, we have started seeing an influx of brute-force amplification attacks, both on our service and the rest of the internet at large. These attacks exploit the XML-RPC functionality in WordPress, as described on Securi.net

You can see if you are being taken down by this attack by running one of the following two commands on your droplet, depending on which webserver you’re running:

Apache: grep xmlrpc /var/log/apache2/access.log Nginx: grep xmlrpc /var/log/nginx/access.log

If you get any results there, it should be easy to fix this issue. If you’ve spun up a WordPress One-Click install droplet since Dec 2015, there’s a small config file which you can enable to block such attacks. We don’t enable it by default because it breaks some commonly used plugins (like Jetpack). Here are the commands you can run:

sudo a2enconf block-xmlrpc
sudo service apache2 restart

Alternatively, Jetpack has functionality to block these requests without impacting other plugins. Check out their Protect module.

If you’re running a WordPress droplet older than Dec 2015 and you don’t want to use the Jetpack plugin from Automattic, you’ll need to configure the droplet manually to block requests to xmlrpc.php:

Apache2 (goes inside your VirtualHost config):

<files xmlrpc.php> 
order allow,deny 
deny from all 
</files>

Nginx (goes inside your server{} block):

location /xmlrpc.php { 
deny all; 
}

Alternatively, if you are not having this issue due to an XML-RPC brute force attack, your Droplet might not have enough memory to deal with your traffic reliably. We recommend users run WordPress on a 1GB droplet or larger.

In order to help reduce your memory usage, you’d first want to check for any plugins using a large amount of memory. There are a lot of memory hungry plugins out there! You may also want to optimize your configuration files.

Below are some great resources that we commonly recommend in support tickets, explaining how to do so, depending on your setup:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

If none of this works, you may have no choice but to resize to a larger sized droplet that can handle your traffic.

Best, Eris Platform Support Specialist

EDIT: If you’re fairly certain you’re not suffering from an xml-rpc attack, check out our article about debugging Wordpress database errors.

EDIT: We now have a community article covering xml-rpc attacks!

Hey there,

As @nestchris said, we have started seeing an influx of brute-force amplification attacks, both on our service and the rest of the internet at large. These attacks exploit the XML-RPC functionality in WordPress, as described on Securi.net

You can see if you are being taken down by this attack by running one of the following two commands on your droplet, depending on which webserver you’re running:

Apache: grep xmlrpc /var/log/apache2/access.log Nginx: grep xmlrpc /var/log/nginx/access.log

If you get any results there, it should be easy to fix this issue. If you’ve spun up a WordPress One-Click install droplet since Dec 2015, there’s a small config file which you can enable to block such attacks. We don’t enable it by default because it breaks some commonly used plugins (like Jetpack). Here are the commands you can run:

sudo a2enconf block-xmlrpc
sudo service apache2 restart

Alternatively, Jetpack has functionality to block these requests without impacting other plugins. Check out their Protect module.

If you’re running a WordPress droplet older than Dec 2015 and you don’t want to use the Jetpack plugin from Automattic, you’ll need to configure the droplet manually to block requests to xmlrpc.php:

Apache2 (goes inside your VirtualHost config):

<files xmlrpc.php> 
order allow,deny 
deny from all 
</files>

Nginx (goes inside your server{} block):

location /xmlrpc.php { 
deny all; 
}

Alternatively, if you are not having this issue due to an XML-RPC brute force attack, your Droplet might not have enough memory to deal with your traffic reliably. We recommend users run WordPress on a 1GB droplet or larger.

In order to help reduce your memory usage, you’d first want to check for any plugins using a large amount of memory. There are a lot of memory hungry plugins out there! You may also want to optimize your configuration files.

Below are some great resources that we commonly recommend in support tickets, explaining how to do so, depending on your setup:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

If none of this works, you may have no choice but to resize to a larger sized droplet that can handle your traffic.

Best, Eris Platform Support Specialist