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
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? |