Re: [PATCH] dtrace probes for memory manager
От | Zdenek Kotala |
---|---|
Тема | Re: [PATCH] dtrace probes for memory manager |
Дата | |
Msg-id | 1260554671.2642.47.camel@localhost обсуждение исходный текст |
Ответ на | Re: [PATCH] dtrace probes for memory manager (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] dtrace probes for memory manager
|
Список | pgsql-hackers |
Robert Haas píše v pá 11. 12. 2009 v 12:55 -0500: > 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? We know that performance impact is less then 1% probably less then 0.6%. The question is if it is acceptable or not. I personally think that it is acceptable. However if not, I will start work on backup solution with dtraced AllocSet and some switching mechanism. But it needs little discussion about design. And first we need decision about current performance impact. Zdenek
В списке pgsql-hackers по дате отправления: