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

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

http://wpdevshed.com/best-wordpress-cache-plugin/

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.

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