Re: [PATCH] dtrace probes for memory manager

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] dtrace probes for memory manager
Date: 2009-11-13 21:41:38
Message-ID: 1258148498.1316.76.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Zdenek

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-11-13 21:43:42 Re: Hot standby, overflowed snapshots, testing
Previous Message Zdenek Kotala 2009-11-13 21:38:07 Re: [PATCH] dtrace probes for memory manager