Finally this helped, none of other solution did any change (add swap, monitor for banned iP's, upgrade droplet):
## Edit /etc/my.cnf, and add the following line under the [mysqld] heading.
[mysqld]
innodb_buffer_pool_size=64M
Then restart: $ service mysql restart
Hi,
I just put this line in. Can you advise that 64M can be given in the basic 512MB server? Will that cause an issue or should I put 32M like suggested below?
thx
With 32M mysql crashed again. I did some checking and looks like it has to do with apache more than mysql. I updated both configurations and I think I have a stable setup now. Take a look at my responses in this other thread:
Thanks @juanbrujo. I have followed your advice and time will tell if it works. But one good indication was that I got this in my error log for mysql (located for me at /var/log/mysql/error.log (or one of the older zipped logs if logrotate is working))
160405 2:12:52 InnoDB: The InnoDB memory heap is disabled
160405 2:12:52 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160405 2:12:52 InnoDB: Compressed tables use zlib 1.2.8
160405 2:12:52 InnoDB: Using Linux native AIO
160405 2:12:52 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
160405 2:12:52 InnoDB: Completed initialization of buffer pool
160405 2:12:52 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160405 2:12:52 [ERROR] Plugin 'InnoDB' init function returned error.
160405 2:12:52 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160405 2:12:52 [ERROR] Unknown/unsupported storage engine: InnoDB
160405 2:12:52 [ERROR] Aborting
After adding the innodb_buffer_pool_size=64M as suggested I still get this line in my log
160405 20:09:05 InnoDB: The InnoDB memory heap is disabled
but the other error, i.e. Fatal "error: cannot allocate memory for the buffer pool" and "Plugin 'InnoDB' registration as a STORAGE ENGINE failed." have not yet raised their heads.
Looks like I can add this line to my.cnf to get rid of that error:
innodb_use_sys_malloc = 0
from here: https://xuri.me/2014/11/10/fix-error-innodb-the-innodb-memory-heap-is-disabled.html
but not sure If i need to do this yet
Is there any other way for SSD as the page tells that configuring SWAP with SSD will have significant impact
This is a pretty common issue with WordPress, certainly not the fault of the DO preconfigured instance as I've experienced the same spinning up my own DO instances as well as back when I used to use AWS EC2. Moving up to an instance with more memory may help temporarily, but you'll likely still eventually come face to face with this issue.
My sites will typically work flawlessly for several months until eventually they start to become plagued with MySQL crashes. My solution almost always ends up being spinning up a new instance and migrating over where the 2-4 month cycle just repeats itself. I've yet to be able to pin down the root cause or a solution.
I've added a swap file but it keeps crashing. Any idea how to find out why it is happening or how to fix it?
Thanks
MySQL instance used to crash once every few months. Lately there was a lot of attempted login on my Wordpress instance and crashes the DB every 2-3 days.
Now I try to restart the DB only to see it eating up all the memory within a minute. I have 1 GB RAM and added 2 GB swap and it runs out of memory in less than 5 mins when I start the DB.
If you have added swap to your droplet and are still experiencing this issue, try tweaking your mysql configuration. You can generate a configuration file here: Percona Tools for MySQL - Percona Configuration Wizard for MySQL (replace my.cnf with the wizard's output and make sure you create a backup first).
I've had this MySQL problem on several droplets. All are Ubuntu 14.04 at present and were originally set up as Wordpress instances. However, I don't use them for Wordpress, so deleting the Wordpress part of the droplet is the first thing I do. This is just for reference.
Initially through this and similar community posts I set up a swap file on each system. But, that never solved my problem on any droplet.
In each instance to date that I've had this MySQL problem I've found that there were MySQL tables that were marked as crashed. Once I ran mysqlcheck to resolve the crash indications it seems I no longer am having problems.
Hope this is helpful.
I had about 3-4 days of continual mysql crashes, but props to @juanbrujo, his solution seems to have helped.
This may be a brute force attack on the wordpress xmlrpc.php.
This was the case for me,
see this: https://www.digitalocean.com/community/questions/unsolveable-epic-mysql-crashes-with-wordpress
I've experienced this as well on several droplets with the preconfigured WordPress setup DO offers. In my case, the servers affected are all running on the smallest hardware package using Ubuntu 14.0.4. Added a swap file to one of them but it didn't make any difference, still keeps crashing.
I'm having the same problem. Did you find a solution?
I'm having exactly the same issue. Did you manage to find a solution?
@Gadz: Try adding swap to your droplet: How To Add Swap on Ubuntu 14.04 | DigitalOcean.
Good idea. I'll try it out. I've been doing some research and memory seems to be the culprit. I've cleaned up memory usage but adding swap should definitely help. Thanks for the suggestion
Having the same issue with a Wordpress on Ubuntu.