MySQL Bugs: #68357: Mysqld not releasing memory

Bug #68357	Mysqld not releasing memory
Submitted:	13 Feb 2013 9:04	Modified:	19 Mar 2013 18:52
Reporter:	Kurt Agius	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.5.29-0ubuntu0.12.04.1-log	OS:	Linux
Assigned to:		CPU Architecture:	Any

Description:
I had a mysql master server running version:
5.1.61-0ubuntu0.11.10.1-log (Ubuntu)

Recently i introduced replication and i added a slave running version:
5.5.29-0ubuntu0.12.04.1-log (Ubuntu)

I have a tool to monitor memory usage and i notice that memory usage is gradually increasing during the day.

I use InnoDB as storage engine and the innodb_buffer_pool_size is set to: 4G.

The server has total 8GB memory. But at one point in atop i can see:
VSIZE: 6.6G and RSIZE: 5.6G

To my knowledge this should be impossible, since i don't have any in-memory tables and no opened connections apart from the slave replication thread.

I tried to stop the slave and start it, but memory was not released.

(not sure if this is relevant or not)
But i have php scripts running on the master server, who are doing very simple select queries on the slave's replication database (have less load over the master server) but since they are PHP scripts, the connections are closed and all memory should be released, so that still shouldn't be the problem.
note: this i confirmed using the SHOW PROCESSLIST and i don't see any open connections.

Any ideas what else can i check ?

How to repeat:
It's difficult to say how to repeat, i would assume that a setup similar to the one i described should have the same issue.
I can provide the my.cnf files on both servers so you can try to repeat the issue.

Memory can also be allocated for things like implicit temporary tables needed for grouping / sorting ...

Also once allocated memory can usually not be returned to the OS unless it is at the very top of the heap (memory fragmentation), so a server process will usually never shrink. 

It should reach a peak size after a while though as freed memory gets reused internally. If on the other hand it grows indefinitely instead of reaching a steady peak you may be hitting a real memory leak ...

To be honest i saw it growing above peak twice because and it was swapping so hard that i had to restart mysql immediately.

But i didn't really take a chance again to see if it keeps on growing above peak because i prefer to avoid that kind of situation.

Is there any other way to check what's really going on ?
I mean, if it's really a memory leak, how can i prove it so i can provide enough information so the issue can be fixed ?

5.5.30 has a few memory leak bugs fixed that exist in 5.5.29.  Also, disable performance_schema as it will not help you track memory usage (and might consume some).  Then, please upload my.cnf, as well as periodic outputs of how much the mysqld process consumes over time..

Agreed, i should upgrade to version 5.5.30 first.

Small question (maybe out of topic, if yes i will figure it out somewhere else):

Anybody knows how linux upgrades packages ?

What i mean is that usually (like in this case) i check the latest version from apt-get for a package (in this case mysql) and the latest version is version 5.5.29 but i know that there's version 5.5.30 available.

I try to avoid compiling it manually, so later i can continue with normal updates, but maybe compiling it manually is the best option.

Thanks for your help.

Thank you for the feedback.

Please upgrade and provide information which Shane requested.

Regarding to upgrade, please use our version available from http://dev.mysql.com/downloads/ You don't need to compile anything, simply use eitehr Debian Linux or Generic Linux binary package.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".