MySql overload using all memory on the droplet

  • Posted July 2, 2013


Im migrated a buddypress site to a droplet with 512mb . and im having some issues.

The first instalation was fine but when i did the dump / export tables from wordpress, the mysql started to crash.

Then i created the swap and it stopped to crash BUT still couldnt use the server.

Then i did the changes on my.cnf and apache.conf ( and i can use it for 1 minute than it overload again but didnt crash

This is my free -m total used free shared buffers cached Mem: 491 482 8 0 1 17 -/+ buffers/cache: 464 26 Swap: 511 506 5

The database only have 8mb… its not possible to be eating all the free memory…


Submit an 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.


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! Regards, Alex

installed memcache and xcache… oh boy… huge difference !

There’s actually 856MB used, the rest are cached. The memory usage looks fine - you shouldn’t experience any more crashes.

I upgrade… <br> total used free shared buffers cached <br>Mem: 995 871 123 0 0 14 <br>-/+ buffers/cache: 856 138 <br>Swap: 1023 584 439 <br> <br>Im afraid it will consume all again… <br> <br>… can i have more than 1 swap file?

I don’t recommend running a whole LAMP stack with InnoDB enabled on a 512MB droplet as it won’t have enough resources and will run out of memory and cause processes to crash. <br> <br>You should upgrade to at least a 1GB droplet.

Seems its not configuration… seems like bad programing… im checking it…

         total       used       free     shared    buffers     cached

<br>Mem: 491 485 6 0 0 10 <br>-/+ buffers/cache: 474 16 <br>Swap: 511 509 2 <br> <br> <br>Does my site have all that traffic and i dont know…? pass another 5 minutes and everthing get back to normal… <br> <br> total used free shared buffers cached <br>Mem: 491 308 183 0 4 42 <br>-/+ buffers/cache: 261 230 <br>Swap: 511 92 419 <br>

It was but wp_users and some aspect of my buddypress use innodb… so i turned it on again but with a few changes… (>… <br> <br>I did some test… always checking free -m to see the memory use… on the first 10minutes… all fine… only using 128mb and no swap (i enter the site… did some stuff there… the memory usage got a little bit high but released after) but … pass the 10 minutes up… it consume everthing again… what could be happening?

MySQL is probably crashing due to running out of memory. Is everything working fine now?

You sir is a life saver… <br> <br>I tried the skip-innodb but with no use… the service wasnt working… didnt knew that innodb was such a memory hungry