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 603c8f070911131421s55eb12deg3b85d96182173bf6@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] dtrace probes for memory manager  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
On Fri, Nov 13, 2009 at 5:20 PM, Zdenek Kotala <Zdenek.Kotala@sun.com> wrote:
> Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
>> Zdenek Kotala wrote:
>> > Attached patch contains new dtrace probes for memory management. Main
>> > purpose is to analyze memory footprint - for example how many memory
>> > needs transaction, peak memory per context, when memory block is reused
>> > or when it is allocate by malloc and so on.
>>
>> Having had to instrument these to figure out some problems, I'd give
>> this patch a +1.  However, the performance argument is compelling.  As a
>> compromise, maybe we could have a #define that needs to be turned on at
>> compile time to enable these probes; so a regular dtrace-enabled build
>> would not have them, but if you really needed to analyze memory
>> allocations, you could recompile to turn them on.
>
> The another idea is to have two AllocSet functions set. One without and
> one with dtrace probes. And switch it by GUC flag for example. From mcxt
> I create and delete context is important, rest can be taken from alloc
> set probes.

I've always thought it was odd that we had a function-dispatch
interface in such a performance-critical path.  But if we really want
to keep it around this might not be a bad thing to use it for.

...Robert


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: [PATCH] dtrace probes for memory manager
Next
From: Zdenek Kotala
Date:
Subject: [patch] executor and slru dtrace probes