Re: [PATCH] dtrace probes for memory manager
От | Zdenek Kotala |
---|---|
Тема | Re: [PATCH] dtrace probes for memory manager |
Дата | |
Msg-id | 1260367469.1422.38.camel@localhost обсуждение исходный текст |
Ответ на | Re: [PATCH] dtrace probes for memory manager (Bernd Helmle <mailings@oopsware.de>) |
Ответы |
Re: [PATCH] dtrace probes for memory manager
Re: [PATCH] dtrace probes for memory manager |
Список | pgsql-hackers |
Bernd Helmle píše v út 08. 12. 2009 v 22:06 +0100: > > --On 8. Dezember 2009 15:51:52 -0500 Greg Smith <greg@2ndquadrant.com> > wrote: > > > Try this instead, which will give you a test where checkpoints have a > > minimal impact, but lots of memory will be thrown around: > > > > pgbench -i -s 10 <db> > > pgbench -S -c 10 -T 600 <db> > > Thanks for the input, will try.... > I modified probes to reduce overhead. Prototype patch is attached. Main point is to remove mcxt_alloc probe and keep only aset_alloc. I did also some testing with interesting results. At first I prepare special C store function (attached) which do only allocation and deallocation and I measured how long it takes: On 32bit the memory allocation is slow down 8.4% and on 64bit it is only 4.6%. Good to mention that I call palloc and pfree but in standard behavior pfree is not much used and memory is freed when context is destroyed. It means that we should think about 4.2% and 2.3% instead. But in normal situation database does also other thing and palloc is only one part of code path. It is why I run second test and use sun studio profiling tools (collect/analyzer) to determine how much CPU ticks cost the probes during pg_bench run. And results are much better. AllocSet alloc function takes about 4-5% and probes assembler code takes 0.1-0.2% on 64bit. I did not test 32bit but my expectation is that it should be about 0.3-0.4%. Zdenek
Вложения
В списке pgsql-hackers по дате отправления: