Wordpress: Error Establishing a database connection - Vesta CP - Works For 30 Seconds After Reboot

Hello, I have several wordpress sites that have been working great on Digital Ocean up until today.

Now, all sites hosted on Digital Ocean are running into “Error Establishing a Database Connection”. (Similar sites I have not using Digital Ocean are just fine.)

When I reboot my droplet, I can connect and do anything I want on the sites for around 30 seconds - and then the database error reappears.

I am using Vesta CP (Vesta Control Panel). At the beginning of this problem I double-checked the username/password etc. for the databases that would also be located in the wp-config.php file. While the sites are down, it also shows “error connecting to localhost”.

Vesta CP also works for around thirty seconds after a quick reboot.

I created a swap file as shown here.

But the problem still persists. Any ideas?


Thanks for your reply.

I’m looking into what could be using so much memory.

In the meantime, using sudo service mysql restart (Ubuntu 14.04) has kept the sites alive for now.

I have the same issue. After some days, I need to restart the SQL server. I created a swap file which helped to have more days between my reboots, but I still have the problem. The WordPress sites I have, have smalls databases, this is not an issue for too much data or requests or anything… I have also Sentora installed on my server to manage the websites, but on another server on which I just have WordPress I don’t have any issue. So it’s maybe only happening when we have a WordPress with a management system.

I’m having the same problem here with 2 of my older droplets.

One droplet I created a couple weeks ago does not have this problem.

I have the same problem and tried a number of suggestions, including upgrading to a 1GB droplet, adding a swap file etc… same problem.

I ended up creating an account here , transferred a copy of my site and it cleared up the problem, improved the performance dramatically and provided us with 24/7 support. This is one of those things where you get what you pay for.

These are usually the symptoms of running out of memory on your server, making the database (the biggest memory consumer) shut down.

You typically see a message in syslog when this happens, showing which process was killed.

The fix is to make your server use less memory, or to add more memory.

Thanks Zetura. A few days ago, I had to do the mysql restart for the second time after doing major site maintenance. I’m still using VestaCP, but it’s good to know that the errors might just be caused by the site manager.

This comment has been deleted

This comment has been deleted

This comment has been deleted

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.

@Zac1 - What size is your droplet? If you’re running a 512MB or 1GB with a Control Panel and multiple WordPress installations, you’re likely to run in to this type of scenario. Most control panels are not all that optimized. They are designed to suit the needs of many, not the few and in most cases, certainly not resource-constrained virtual server instances. While cPanel, as an example, will run on a 1GB VPS or Droplet, that doesn’t mean that it’ll run efficiently. Despite ongoing optimizations, cPanel is still a relatively heavy control panel.

I’ve not spent a great deal of time with VestaCP, though if you’re running VestaCP, ClamAV, SpamAssassin, PHP(-FPM/CGI), NGINX, MySQL and let’s just say 2-3 other services, plus throwing a handful of semi-active WordPress installations with around 5-10 plugins each on top of the stack, you’ll need to be able to tune PHP, NGINX and MySQL (to start) along the way. VestCP doesn’t do this for you (nor will any control panel), and most software installs are either direct from the OS repositories or a slightly modified version (configuration wise) that the developers felt was a suitable release candidate (not to place the blame on the developers, there’s not a magic cookie-cutter solution when it comes to optimization or security – they are simply providing a best-effort).

In most cases, the default configurations for PHP, NGINX and MySQL are horrible and pretty much require modification out of the box for stable service on a server that sees even low levels of traffic.

That being said, on the client side, I would advise looking in to a caching plugin and ensuring that either OpCode Cache is enabled in your php.ini file to take full advantage of object caching. The link below compares numerous caching plugins and I would advise giving it a look over entirely before installing any of them.

If object & file caching do not provide a solution, the only true option is going to be diving in to the configuration for PHP, MySQL and NGINX. I will say that, by taking this approach, backup your configuration files first and then modify a copy of them. This way you have a fallback.

Hello all,

This crash is most likely due to your system running out of memory. I’d suggest that you add a swap file to give yourself a bit more of a buffer. Check out this tutorial:

How To Add Swap on Ubuntu 18.04

What you can also do is to use the MySQLTuner script.

The MySQLTuner is a script written in Perl and allows you to quickly test your MySQL configuration and it gives you suggestions for adjustments to increase performance and stability.

According to the official GitHub page, it supports 300 indicators for MySQL/MariaDB/Percona Server in this last version.

To run the script you could do the following:

  • SSH to your Droplet
  • Download the script:
wget -O
  • Then execute it:

The script would run multiple checks against your MySQL instance, all checks done by MySQLTuner are documented here.

Also as stated in the official documentation, it is still extremely important for you to fully understand each change you make to a MySQL database server. If you don’t understand portions of the script’s output, or if you don’t understand the recommendations, you should consult a knowledgeable DBA or system administrator that you trust.

As a good practice make sure to always test your changes on staging environments before implementing them on your production database.

On the same note, if you want to have worry-free MySQL hosting and focus on your application, I would recommend trying out the DigitalOcean Managed Databases:


Hope that this helps! Regards, Alex

This comment has been deleted

I had this issue. However, after ssh in my server and ransudo service mysql restart my site was back up