Announcement

Announcement Module
Collapse
No announcement yet.

slowly growing memory usage

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    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*
    MariaDB-common-5.5.31-1.x86_64
    MariaDB-server-5.5.31-1.x86_64
    MariaDB-compat-5.5.31-1.x86_64
    MariaDB-client-5.5.31-1.x86_64

    The my.cnf file is at http://www.rewtemplates.com/mariadb/mariadb_conf.txt.
    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 http://www.rewtemplates.com/mariadb/mariadb_cacti.pdf
    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.

  • #2
    I think my googleing has finally turned up something.

    https://mariadb.atlassian.net/browse/MDEV-4754
    https://bugs.launchpad.net/percona-server/+bug/1170103

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

    Comment


    • #3
      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.

      Comment


      • #4
        @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...

        Comment


        • #5
          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" 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.

          Comment

          Working...
          X