Patches for MySQL by Percona

Possible memory leak in the MySQL Binaries Percona build10

Reported by Evgeniy Stepchenko on 2009-01-09
6
Affects Status Importance Assigned to Milestone
Percona patches
Incomplete
Low
Unassigned

Bug Description

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

Changed in percona-patches:
assignee: nobody → yasufumi-kinoshita
importance: Undecided → High
nicholas (nicholas-linpro) wrote :

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

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

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

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

Changed in percona-patches:
importance: High → Low
status: New → Incomplete

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers