Possible memory leak in the MySQL Binaries Percona build10

[Evgeniy Stepchenko]

Hello, we have been using the 67-b10 version since around release, and we see a memory usage development that would indicate a memory leak?

Server version: 5.0.67-percona-highperf-b10-log MySQL Percona High Performance Edition (GPL)

http://nicholas.users.linpro.no/mysql-memory-month.png

Week 50 we ran stock redhat mysql . Early week 51 we installed the percona version. since then memory usage has been growing. Last week orso it ran out of swap space, so we added some more today ;)

We also run http://www.percona.com/mysql/5.0.68/RPM/rhel5/ another place, without the same problems.

greetings
-nicholas

[nicholas (nicholas-linpro)]

We "downgraded" to
Server version: 5.0.68-percona-highperf-3-log MySQL Percona High Performance Edition (GPL)
http://www.percona.com/mysql/5.0.68/RPM/rhel5/

And since then have had a dead stable memory usage, see attachment.
Same hardware, same load, same my.cnf settings, except innodb_buffer_pool_size adjusted from 10G to 9G.

Let me know if there is any more information I can provide.

:)
-nicholas

[Yasufumi Kinoshita (yasufumi-kinoshita)]

nicholas,

Sorry, I couldn't specify which source file may have problem by current information.

Please tell me the full information from "show global variables;" and "show innodb status\G" at the memory leak.

Thank you,
Yasufumi

[nicholas (nicholas-linpro)]

Yasufumi Kinoshita wrote:
> nicholas,
>
> Sorry, I couldn't specify which source file may have problem by current
> information.
>
> Please tell me the full information from "show global variables;" and
> "show innodb status\G" at the memory leak.
>
> Thank you,
> Yasufumi
>

Hello,
this was a hot production system, so we have replaced the troublesome
-67 version with a less patched -68 version. So unfortunately we do not
have show innodb status\G or show global variables\G from the leaking
system. Vadim got a copy of my.cnf and global variables, from when the
system already was "downgraded" to -68.

Since then our memory usage has been dead stable. Since it is a hot
production sytem we do not want to experiment too much. Our test systems
with the same builds did not show the same results, so we might have to
tag this unreproducible and just keep an eye open for possible memory leaks.

-nicholas

[Evgeniy Stepchenko (evgeny-stepchenko)]

Currently we have no sufficient information. Lets keep an eye open.

[Piotr Gackiewicz (gacek-intertele)]

I have observed similar behaviour when "userstat patch" is on.
MySQL 5.0.77 + percona patches, compiled on my own.
We run hosting with 600 databases, 28k tables, most of them are of MyISAM type (1k of InnoDB type).

It was strange: mysql patched with userstat patch worked well for three weeks, and then suddenly memory consumption started to grow exponentially.

After mysqld restart - still exponential memory consumption.
At peak, it was consuming additional 20 MB every 20 seconds.

Had to switch userstat_running off, something is broken there.