Re: [PATCH] dtrace probes for memory manager
От | Robert Haas |
---|---|
Тема | Re: [PATCH] dtrace probes for memory manager |
Дата | |
Msg-id | 603c8f070911131421s55eb12deg3b85d96182173bf6@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] dtrace probes for memory manager (Zdenek Kotala <Zdenek.Kotala@Sun.COM>) |
Список | 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 по дате отправления: