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

Posted November 2, 2015 20.2k views

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?

  • 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 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 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.

  • 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.

  • Show 4 more comments

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.

Submit an Answer
4 answers

@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.

  • Thanks for your reply and good advice. I have a 1 GB droplet, but I would not call my 2-3 installations very extensive.

    • @Zac1 - No problem. I would run top as root or your sudo user and once running, use shift + m followed by c to sort the processes by memory usage and expand the command. This will give you a more in-depth look at what processes are using the most memory and will allow you to more easily identify them live.

      The issue is that WordPress can, on its own, request quite a bit of RAM and, if it’s unable to allocate, it’ll fail. For instance, /wp-admin/ alone can request up to 256MB if PHP is setup in a manor that allows RAM to be assigned on-demand (using ini_set as an example). You can set options in wp-config.php to limit or expand the amount of RAM WordPress is allowed to use, though IIRC, this doesn’t affect /wp-admin/ – it’ll still request the 256MB regardless.

      So, if we have 3 instances, that comes out to 768MB’s that can be requested if all 3 are active at the same time. Of course, this isn’t a request that locks up the 768MB indefinitely, though if the request is made at the same time MySQL or another process is trying to request the same, more or less – really any amount that is free, thus pushing you in to SWAP or beyond, errors are going to start popping up. SWAP, even on an SSD HD, is still far slower than RAM by multitudes.

      • /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/ --socket=/var/run/mysqld/mysqld.sock --port=3306

        This occasionally jumps to the top, using >10% of memory. Before I dive into mysql, any ideas? Thanks.

        I also have a 5 GB swap file in use.

        • @Zac1 - I would head over to and follow the installation instructions under “Download/Installation.” MySQLTuner is a nice little utility that can provide some insight as to what may be wrong. It’ll provide details on how effective your query cache is (or isn’t) as well as insight on other configuration areas that we’d primarily need to look at.

          For the sake of keeping the conversation clean, I’d post the output in a PasteBin and link to that here so that you’re not posting nearly a page of output :-).

          The snippet you referenced above is the MySQL Daemon. Unless you’re spawning multiple daemon processes, the MySQL Daemon is going to report higher usage as it’s responsible for the connection/processes.

        • @Zac1 - Breaking down that line:

           --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/ --socket=/var/run/mysqld/mysqld.sock --port=3306

          Tells MySQL to run as the mysql user.

          Location of your MySQL Error Log

          MySQL Process ID File

          MySQL Socket

          The (default) port that MySQL is configured to run on.

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

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!