Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

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!
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.
Hello friend!
I’m sorry about the trouble you’re having here. Let’s ignore the phpMyAdmin thing, it’s a rabbit hole that won’t solve the underlying issue. What you are dealing with is something that so many people deal with who run their own servers. In fact, if you search for the error you will find people everywhere talking about dealing with it for the first time in mass quantities. This to say, MySQL crashes are not at all uncommon. The most common reason for this is the system running out of memory. The quickest short term fix is to log in via SSH or the web console and run “service mysql restart” (“mysqld” for CentOS/Fedora).
There are a few ways to resolve this problem to prevent this from happening again.
https://www.digitalocean.com/community/tutorials/how-to-resize-your-droplets-on-digitalocean
You can get an example of the memory usage from your current or proposed settings with this calculator: http://www.mysqlcalculator.com
Take note that upgrading the droplet is an option, but hardly the one I recommend. Number 3 in my list there is key. The thing about Wordpress is that a 1GB droplet might house one Wordpress site well, and for someone else a 64GB droplet might fail to house their website well. This is why you have to be careful with just upgrading the droplet. I don’t want you to pay more only to find that it doesn’t help you. I only want you to do that if it truly ends up being the only option. The reason droplet size may not have a significant impact is that plugins and themes are capable of driving Wordpress resource needs through the roof. Raising the ceiling seems like the right reaction, but if the problem is bad enough then the problem will simply scale up to the new ceiling and hit the same problem. These are my go to rules for optimizing Wordpress:
Keep in mind that some plugins and themes can render static caching ineffective, and in such cases the only thing that you can really do is try to find out which is the cause and consider an alternate solution.
Kind Regards, Jarland
Thank you for taking the time to respond to my question. I added a swap as instructed in this tutorial. I’ve restarted MySQL using the following command: service mysql restart. I’ve powered my droplet off then back on again. I checked the memory usage with the df -h command and am receiving the following results:
Filesystem Size Used Avail Use% Mounted on
udev 487M 0 487M 0% /dev
tmpfs 100M 3.1M 97M 4% /run
/dev/vda1 29G 3.9G 26G 14% /
tmpfs 497M 0 497M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 497M 0 497M 0% /sys/fs/cgroup
/dev/vda15 105M 3.4M 102M 4% /boot/efi
tmpfs 100M 0 100M 0% /run/user/1000
Additionally, the site was regularly updated and was cached with WP Rocket, a premium caching plugin which yields much better results with less chance of conflict when compared to WP Super Cache and W3 Total Cache.
I’m not convinced this is a memory issue as you’ve suggested, though I’m more than willing to admit I’m not certain one way or the other… I’m still new to server management. Thanks again for your help!