List:Internals« Previous MessageNext Message »
From:MARK CALLAGHAN Date:June 4 2009 9:05pm
Subject:Re: Profiling a storage engine
View as plain text  
On Thu, Jun 4, 2009 at 1:58 PM, Slava Akhmechet <coffeemug@stripped> wrote:
> Mark,
>
> On Wed, Jun 3, 2009 at 8:01 PM, MARK CALLAGHAN <mdcallag@stripped> wrote:
>> I have never had any luck using gprof on multi-threaded servers. If
>> you use Linux, then oProfile works great for flat profiles and Google
>> perftools works great for hierarchical profiles.
> Thanks for your reply. We're interested in understanding how much time
> is spent in each part of our code. oProfile is great, but it mostly
> gives information for CPU bound applications. Unfortunately it's not
> very useful when you need to understand IO blocking behavior.

Even if gprof were to work for multi-threaded servers, it wouldn't
give you that data. You want to profile based on wall clock time to
include the overhead when things are blocked as well as when they are
running on a CPU.

I want the same thing and I am not sure a tool exists to provide it.

>
> We're tracking IO/CPU/page cache statistics as we're running
> benchmarks. This gives us a reasonably complete picture, but it still
> forced us to take too many guesses. We're curious how others profile
> storage engines - we have bits and pieces of information on
> performance, but integrating it into a complete picture still involves
> too much guesswork.
>

My goal is to have support in Innodb to start/stop timers on all
events (IO, synchronization) where a thread may block and then I can
combine that output with oprofile output to determine where all of the
time is spent. Alas, I won't have call stacks for the places where
timers are started/stopped.

-- 
Mark Callaghan
mdcallag@stripped
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