slowly growing memory usage

Hello Experts

I’m trying out mariadb on a vm, but the memory usage just keeps growing until oom-killer kills it off. I’d like some advice on where to try digging to get this under control.

top output

top - 20:38:44 up 33 days, 1:20, 2 users, load average: 0.04, 0.21, 0.27
Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
Cpu(s): 15.6%us, 0.7%sy, 0.0%ni, 82.7%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1020584k total, 955876k used, 64708k free, 2816k buffers
Swap: 499704k total, 81912k used, 417792k free, 220588k cached

23314 mysql 20 0 1376m 662m 5300 S 16.0 66.5 1215:31 mysqld

cat /etc/redhat-release

CentOS release 6.4 (Final)

rpm -qa MariaDB*


The my.cnf file is at [URL][/URL].
You can see that even though the buffer pool is set to 256M, mysqld is using over double that.

Cacti graphs (using the percona graphs) for the past week can be found at [URL][/URL]
I last changed some settings and restarted mysqld on Friday. As you can see, memory usage has been climbing ever since very slowly and is now starting to swap parts of mysqld.

MySQLTuner 1.2.0 says
[–] Total buffers: 320.0M global + 2.8M per thread (100 max threads)
[OK] Maximum possible memory usage: 598.1M (60% of installed RAM)

And since I’m nowhere near my max connections (highest usage since restart is 16) I just cant understand how I’m using over 650M of RAM. I know the calculations MySQLTuner does aren’t perfect, but I’m still baffled.

vm.swappieness is set to 20.

Let me know if I’ve missed an helpful details.

I think my googleing has finally turned up something.


I just turned off the query cache and will report my results tomorrow.

MariaDB also uses XtraDB engine from Percona, so it can be the same bug. In Percona Server this problem was present only in 5.5.30-30.2, and no longer exists in 5.5.31. And yes, turning off the query cache is a proper workaround here.

@przemek , question: how is turning off the query cache a solution here? Sounds like removing an totally relevant part of the performance component of the server…

gsosa: turning off the query cache is not a solution, it is just a workaround to avoid hitting this particular bug. The real solution is to upgrade to a version where this bug is fixed, so that you can keep using the query cache if you really need it.

On the other hand, I would argue with this query cache description: “totally relevant part of the performance component of the server” :slight_smile: The truth is query cache may be beneficial for some workloads, but usually it’s rather a source of contention and very often having it disabled gives better results.