MySQL on Ubuntu Keeps Crashing

Posted June 17, 2013 88.3k views
I've got an Ubuntu 12.x Droplet running, and for some reason MySQL keeps crashing to where I need to go in and restart the process ('sudo service mysql restart'). I'm not even sure how to start debugging this - could anyone give me some guidance on how to start? My MySQL logs are empty in /var/log/ Thanks!

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.

25 answers

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.

Then restart: $ service mysql restart

  • I configured mine to be 32M and it’s not crashed since; thanks!

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


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

    but not sure If i need to do this yet

  • OK i will try, keep in touch....

  • for me, that file is located in /etc/mysql/my.conf

MySQL could be running out of memory - try adding swap to your droplet:
by Etel Sverdlov
Linux swaps allow a system to harness more memory than was originally physically available. Here's how to set up a linux swap file on Ubuntu 12.04
One rule of thumb I use when configuring a droplet with MySQL is I get all my processes running, then use top or landscape-sysinfo to see how much memory is free. Then I divide my free memory in half, that number is usually about 8-10M. Then I set the InnoDB buffer size to that amount to avoid having MySQL use up too much memory. This has cleared up 99% of my problems with MySQL crashing.
innodb_buffer_pool_size = 10M

It can also help to use swap space, but it's best to increase the size of your droplet as it degrades Digital Ocean's hardware to use swap.

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.

grep for "OOM" in /var/log/syslog & /var/log/dmesg, it's usually a out of memory issue.
You might want to optimize your configuration as well, take a look at MySQLTuner:
i've got the same issue like your with a 512mb ram droplet

after adding a 512mb swap to my droplet the SQL crash seem like went away
Thanks. I was having the same problem - we'll see if this resolves the issue. Also. Can you give me an example of grepping for "OOM" in /var/log/syslog specifically?
Adding swap to your droplet (first comment) solving this problem.
i have added a 512 swap but face the same issue, my swap is on but is it possible that its not working fine?
@waqas464: Check MySQL's error logs to see why it's crashing.
I am glad I came across this question as I am having the same problem! I am on the same setup as nhatkhoa. It was based off of your MySQL image when I created the droplet. I added swap, and made a few adjustments based on an answer at StackExchange (

It seems like those two things made mysql less prone to crash, but I can still do it if I load 16 tabs at once pulling from each of my sites using mysql.

I have the last several lines of output from my error log that I have posted to dropbox, so that I don't muck up this thread. That can be read at

Any thoughts Kamal? Thanks in advance for your help.
Hmm. I had already done that. It doesn't seem to clear up those lines. Still keeps crashing. I have even tried switching my tables to InnoDB, but no luck.
I'm having the same issue with wordpress installs, could be strange characters being injected by spammers (not sure if this is a problem or not)
Same issue to me. Can't find the solution yet :(
Same issue to me. Can't find the solution yet :(
Had the same issue on the droplet of 512Mb RAM and solved it only by upgrading to 1Gb
I just fixed it by adding a new swap file, I hope this will fix the issue for someone else, mine issue was caused by misconfiguration during the installation process, here is the link for the instruction :


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?


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.

I still have the same problem. Did someone definitely solve this issue?

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:


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 a worry-free MySQL hosting and focus on your application, I would recommend trying out the DigitalOcean Managed Databases:

This was mini tutorial was posted from bobbyiliev in this question in our community:

Hope that this helps!

Submit an Answer