Error establishing a database connection (WordPress)

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…

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

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

Sign In or Sign Up to Answer

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.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

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

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 

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:




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

It seems like MySQL is running out of RAM and crashing. You could add swap and see if that helps (<a href=“”></a>), or upgrade your droplet to the next plan so that there’s more RAM available for MySQL.

As we know, a shared host like Bluehost has more direct control over your server. On DO, you are required to maintain the server, and that means things that you might not need to deal with on other hosts come up here.

I was made aware of this exploit by the DO team.

After implementing the apache.config solution, my problems stopped.

[Apache VirtualHost Config] <VirtualHost> … <files xmlrpc.php> order allow,deny deny from all </files> </VirtualHost>

This attack is affecting all wordpress sites, but if you were using another host before, you may not have noticed. In my experience with Bluehost, I have had them suspend my account because I was attacked by comment spam, I suspect something similar to that would have occurred in this instance as well.

Unfortunately DO has been very slow to address this issue with the community as it seems everyone is in the dark about it.