Re: [PATCH] dtrace probes for memory manager

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, Greg Smith <greg(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] dtrace probes for memory manager
Date: 2009-12-11 17:59:38
Message-ID: 1260554378.2642.42.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas píše v čt 10. 12. 2009 v 23:55 -0500:
> On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com> wrote:

> >
> > But in normal situation database does also other thing and palloc is
> > only one part of code path. It is why I run second test and use sun
> > studio profiling tools (collect/analyzer) to determine how much CPU
> > ticks cost the probes during pg_bench run. And results are much better.
> > AllocSet alloc function takes about 4-5% and probes assembler code takes
> > 0.1-0.2% on 64bit. I did not test 32bit but my expectation is that it
> > should be about 0.3-0.4%.
>
> There's not really enough detail here to determine what you tested and
> what the results were, and I don't think this patch has any chance at
> all of getting committed without that. Please clarify.
>
> If there's some real-world test where this probe costs 0.3%-0.4%, I
> think that is sufficient grounds for rejecting this patch. I
> understand the desire of people to be able to use dtrace, but our
> performance is too hard-won for me to want to give any measurable of
> it up for tracing and instrumentation hooks that will only be used by
> a small number of users in a small number of situations.
>

As I mentioned I run pg_bench -c10 -t1000 and collect data from
backends. collect and analyzer is similar tool to gprof.

Zdenek

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2009-12-11 18:04:31 Re: [PATCH] dtrace probes for memory manager
Previous Message Joshua D. Drake 2009-12-11 17:59:27 Re: Python 3.1 support