Re: [PATCH] dtrace probes for memory manager - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] dtrace probes for memory manager
Date
Msg-id 603c8f070912110955l28a0d9a1m545b5cc75c3d02c0@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] dtrace probes for memory manager  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: [PATCH] dtrace probes for memory manager  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Re: [PATCH] dtrace probes for memory manager  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Dec 11, 2009 at 12:55 PM, Zdenek Kotala <Zdenek.Kotala@sun.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@commandprompt.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?

...Robert


pgsql-hackers by date:

Previous
From: "David P. Quigley"
Date:
Subject: Re: SE-PostgreSQL/Lite Review
Next
From: Zdenek Kotala
Date:
Subject: Re: [PATCH] dtrace probes for memory manager