Re: [PATCH] dtrace probes for memory manager

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] dtrace probes for memory manager
Date: 2009-11-13 22:16:15
Message-ID: 603c8f070911131416u76f623cagefe6938de8f3724f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 13, 2009 at 4:41 PM, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)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.
>
> But point of dtrace probes is that they are here without
> recompilation :(. Do we have any test which we could use for performance
> penalty testing? I don't think that overhead is significant.

Don't think. Benchmark. :-)

(If you can measure it at all, it's too much, at least IMHO.)

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2009-11-13 22:20:48 Re: [PATCH] dtrace probes for memory manager
Previous Message Andres Freund 2009-11-13 22:10:26 Re: next CommitFest