Re: testing ProcArrayLock patches

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Subject: Re: testing ProcArrayLock patches
Date: 2011-11-18 22:36:31
Message-ID: 201111182336.31959.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, November 18, 2011 11:12:02 PM Andres Freund wrote:
> On Friday, November 18, 2011 09:16:01 PM Kevin Grittner wrote:
> > Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > When doing line-level profiles I would suggest looking at the
> > > instructions.
> >
> > What's the best way to do that?
>
> I think opannotate -a -s produces output with instructions/code
> intermingled.
>
> > > I don't think cache line contention is the most likely candidate
> > > here. Simple cache-misses seem far more likely. In combination
> > > with pipeline stalls...
> > >
> > > Newer cpus (nehalem+) can measure stalled cycles which can be
> > > really useful when analyzing performance. I don't remember how to
> > > do that with oprofile right now though as I use perf these days
> > > (its -e stalled-cycles{frontend|backend} there}).
> >
> > When I run oprofile, I still always go back to this post by Tom:
> > http://archives.postgresql.org/pgsql-performance/2009-06/msg00154.php
>
> Hrm. I am on the train and for unknown reasons the only sensible working
> protocols are smtp + pop.... Waiting.... Waiting....
> Sorry, too slow/high latency atm. I wrote everything below and another mail
> and the page still hasn't loaded.
>
> oprofile can produces graphes as well (--callgraph). for both tools you
> need -fno-omit-frame-pointers to get usable graphs.
>
> > Can anyone provide such a "cheat sheet" for perf? I could give that
> > a try if I knew how.
>
> Unfortunately for sensible results the kernel needs to be rather new.
> I would say > 2.6.28 or so (just guessed).
>
> # to record activity
> perf record [-g|--call-graph] program|-p pid
>
> # to view a summation
> perf report

> # get heaps of stats from something
> perf stat -ddd someprogram|-p pid

> # show whats the system executing overall
> perf top -az
>
> # get help
> perf help (record|report|annotate|stat|...)
>
...
I forgot that there is also

# get a list of event types
perf list

# measure somethign for a specidif event
perf (record|stat|top) -e some_event_type

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Szymon Guz 2011-11-18 22:37:38 Re: Should a materialized view be based on a view?
Previous Message Kevin Grittner 2011-11-18 22:26:43 Should a materialized view be based on a view?