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