Comments on: Wanted: Better memory profiling for MySQL

By: Matthew Kent

Matthew Kent — Wed, 21 May 2008 16:36:23 +0000

Though I have a rough idea I’d love more insight into where memory is going, right now its just this big blob I hope never runs into swap

I’ve only had to do it once but the only value I’ve had luck in reducing memory consumption was lowering innodb_buffer_pool_size.

By: peter

peter — Wed, 21 May 2008 07:43:17 +0000

Thanks Matt,

Do I read you correctly it is “not be usable in production” ? or is it a typo.

I think with Dtrace at Sun you guys understand it is profiling in production which is very important. It is often not an option to install other version with some debugging enabled and try to repeat the same situation.

By: Matt Ingenthron

Matt Ingenthron — Tue, 20 May 2008 23:22:53 +0000

It’s not quite at the “SHOW STATUS” level, but Domas and I were talking about this area a bit at the MySQL User’s conference. Perhaps you could use the umem memory allocator in some of these cases? It can be LD_PRELOADed and help you, if you set the right environment variable options, determine where the memory allocations have come from. It’s also designed to not be usable in production.

https://labs.omniti.com/trac/portableumem

It was a user space port of the Solaris kernel memory allocator (now copied in Linux/BSD/Windows and others) along with many of the debugging tools. The OmniTI guys liked it so much on OpenSolaris, they ported it to other platforms and use it when building their software after it was released as OpenSource.

One good overview is here: http://blogs.sun.com/ahl/entry/solaris_10_top_11_20

By: Jeremy Cole

Jeremy Cole — Mon, 19 May 2008 14:16:38 +0000

Hi Peter,

Some time ago, I wrote an incomplete proposal for this:

http://jcole.us/blog/mysql/proposal-for-constraining-memory-usage/

It might be an interesting read.

Regards,

Jeremy