From: Kristian Nielsen Date: March 16 2009 7:13am Subject: Re: Valgrind, MySQL - a single query mem check List-Archive: http://lists.mysql.com/internals/36391 Message-Id: <87mybm549a.fsf@knielsen-hq.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Patrick Lau writes: > Unfortunately there is a memory leak in our code. Running the same > query several times increases the memory consumption of mysqld: in > Megabytes (9, 23, 90, 90, 90 ...) Is this in stock MySQL code (do you have a test case/query to show)? Or is it only with your private modifications of the source? > I'm trying valgrind to detect the leak, but it gives me this.... > > LEAK SUMMARY: > ==30826== definitely lost: 2,828,751 bytes in 117,812 blocks. > ==30826== indirectly lost: 2,619,022 bytes in 75,051 blocks. > ==30826== possibly lost: 2,012 bytes in 72 blocks. > ==30826== still reachable: 3,058,698 bytes in 93,895 blocks. > ==30826== suppressed: 0 bytes in 0 blocks. > > ~2MB definitely lost... not the number I expected... That shows 8.5 mb leaked, not 2 ... Also note that the Valgrind numbers are memory returned by malloc(). The process size you see from `top` etc. is memory given by the kernel to the libc malloc() pool, and that will usually be somewhat bigger, as libc will request memory from the kernel in bigger batches. > I think LEAK SUMMARY is about the whole process... Is there a way to > check mem consumption of a query thread using valgrind? How would you > handle such a case? You could try using the macro VALGRIND_DO_LEAK_CHECK (from memcheck.h) in an appropriate place in the code. I haven't tried it myself, but if you call it after running each query, you should get multiple reports, and you can use the delta between them to see the effect of a single query. Note that "still reachable" will likely be much higher, as some memory is not de-allocated until mysqld exit. Hope this helps, - Kristian.