List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:June 4 2009 9:24pm
Subject:Re: Profiling a storage engine
View as plain text  
hi!

>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:

MARK> On Wed, Jun 3, 2009 at 7:17 PM, Slava Akhmechet <coffeemug@stripped>
> wrote:
>> Hi,
>> 
>> We're at a point where we need to understand performance bottlenecks
>> of our storage engine and we're not sure how to proceed. What is the
>> best way to do profiling? We are running benchmarks that compare our
>> performance, cpu utilization, and IO throughput to MyISAM. We're also
>> using procsystime to give us a picture of how much time we spend on
>> various system calls. However, we're not sure how to best make sense
>> of the numbers. We'd like to run gprof, but we're not sure how to
>> compile MySQL to support it, and whether it will give realistic
>> numbers.
>> 
>> We'd appreciate if anyone could share their experience on how to
>> effectively profile a storage engine.

MARK> I have never had any luck using gprof on multi-threaded servers. If
MARK> you use Linux, then oProfile works great for flat profiles and Google
MARK> perftools works great for hierarchical profiles. But to use perftools,
MARK> you need to make some changes to the server.

gprof should work fine with MySQL.
At least I have in the past run the sql-bench benchmark with gprof
with good results.

In theory, to compile with gprof on intel/amd you should just have to
build with:
./BUILD/compile-pentium64-gprof

MARK> This blog post references code that has the changes. The key change is
MARK> to call a perftools function when a thread is created --
MARK> http://mysqlha.blogspot.com/2009/03/more-on-using-google-perftools-with.html

Thanks for the information!

Regards,
Monty
Thread
Profiling a storage engineSlava Akhmechet4 Jun
  • Re: Profiling a storage engineMARK CALLAGHAN4 Jun
    • Re: Profiling a storage engineSlava Akhmechet5 Jun
      • Re: Profiling a storage engineMARK CALLAGHAN5 Jun
    • Re: Profiling a storage engineMichael Widenius5 Jun
      • Re: Profiling a storage engineMARK CALLAGHAN5 Jun
        • Re: Profiling a storage engineMichael Widenius5 Jun
  • Re: Profiling a storage engineAntony Dovgal5 Jun
  • Re: Profiling a storage engineMarc Alff5 Jun
    • Re: Profiling a storage engineSlava Akhmechet8 Jun