Re: [PATCH] dtrace probes for memory manager

Robert Haas píše v pá 11. 12. 2009 v 12:55 -0500:
> On Fri, Dec 11, 2009 at 12:55 PM, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com> wrote:
> > Bernd Helmle píše v pá 11. 12. 2009 v 17:13 +0100:
> >>
> >> --On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
> >> <alvherre(at)commandprompt(dot)com> wrote:
> >>
> >> >>
> >> >> without compiled probes: AVG(2531.68)
> >> >> with compiled probes: AVG(2511.97)
> >> >
> >> > Were the probes enabled?
> >>
> >> Hmm, they were just compiled in, i didn't anything to instrument them with
> >> dtrace.
> >>
> >> I've just started a pgbench/dtrace run with instrumented probes aset_alloc,
> >> aset_free and aset_realloc which just counts the calls to them during
> >> pgbench, the first run gives me
> >>
> >> tps = 1035.045523 (excluding connections establishing)
> >>
> >> Ideas?
> >
> > When probes are activated they have performance impact. It is normal.
> > Important is that you can use it when you need it on production system.
> > No recompilation, no extra binary, no downtime and it is safe.
> > Performance impact depends on Dscript
>
> Yeah. The problem here is the impact when the probes aren't enabled.
>
> I thought we had an idea of using the AllocSet dispatch mechanism to
> make this zero-overhead in the case where the probes are not enabled.
> What happened to that notion?

We know that performance impact is less then 1% probably less then 0.6%.
The question is if it is acceptable or not. I personally think that it
is acceptable. However if not, I will start work on backup solution with
dtraced AllocSet and some switching mechanism. But it needs little
discussion about design. And first we need decision about current
performance impact.

Zdenek