Hello, @benmateev

Could you please let us know which are the exact daily and weekly crons you’re referring to? Also have you made any recent changes to the MySQL configuration and any changes to the server close to when the issues started?

When you ssh to the server and MySQL is not running what was the exact output of the mysql status command?

Hey @alexdo,

thank you for following up on my question -

I have not made any changes to any config files, I setup ssl after the machine was spun up and havent touched a thing afterwards. The error is in the anacron cron job. If I try to post the log output here my post gets rejected as spam, so here is a gist - https://gist.github.com/benjaminmateev/130eb9f5d193afb76f99e8142b293958

And when I get the error and run mysql status I get that it cannot connect localhost server and that it cannot connect through the standard socket because mysql is not running

You might also try adding a swap file to your Droplet to see if it helps reduce or eliminate the crashes. This post details how you can do that.

https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-18-04

Hello,
I’m having the same issue so thanks for the explanation and the solutions.
I’ll try some, hoping it would work for me.

@johngannon thank you so much for the article. I added the swap file since the instance did not have any. Will observe but there was no issue with out of memory errors so I am not sure this is the reason why MySQL decided to stop running. Wouldnt I have also found some kind of error log with that message somewhere on the VM?

It sounds like the OOM killer. It would be helpful to try to confirm this, though. You might have some success with;
dmesg | egrep -i 'killed process'

Adding swap might prolong things however when services that are memory intense it might simply degrade the performance of your system.

What size droplet are you using? Have you got monitoring enabled?

A

Thank you @andmoo I ran the command and did not get any output, so nothing in there.

I have monitoring enabled, no spikes or anything weird looking in the graphs from what I can see. This is currently running on the smallest, 1GB Memory, 25GB Disk node.

free -h shows the following, where the 83M free on Memory is interesting, given the total and used.
root@definingthenextdecade:~# free -h
total used free shared buff/cache available
Mem: 985M 179M 83M 5.4M 722M 635M
Swap: 1.0G 780K 1.0G

@benmateev

thanks for the update. I’d remain confident that the applications are competing for the little spare RAM on the Droplet. Depending on what’s installed on your WP instance and what kind of traffic you’re seeing you could be cutting it fine with memory on a small droplet such as this.

In my experience you have some options now;

1. Upgrade the droplet
2. Analyse and tune MySQL queries using PMM/pt-query-digest (or tune Apache2 for memory usage)
3. Move your database to a dedicated Droplet.

I understand that budget could be a factor here but you’ve bought some time with the swap space and at some stage, if your WP instance starts to pick up more traffic you might see an issue sooner rather than later.

BR

Andmoo

Hey everyone,

it happened again, actually twice, now I am going through logs and I dont see any error, nothing, no spikes, no weird requests, memory is fine, the swap file didn’t help.

It feels like there is something wrong, but the answer for this error are the same in a lot of threads on this page and I dont see an answer that has actually helped, unfortunately.

I am gonna upgrade the droplet as a next step to see whether that helps, though I am already using W3 Cache and Cloudflare as a CDN. I get the feeling that there is some basic error in the configuration of the droplet that keeps coming back - espcially given that I have experienced the same error with the same results and no help from the logs for the past few years trying to one a One-Click Install droplet.

Ben