On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala <zdenek.kot...@sun.com> wrote: > Bernd Helmle píše v út 08. 12. 2009 v 22:06 +0100: >> >> --On 8. Dezember 2009 15:51:52 -0500 Greg Smith <g...@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%.
There's not really enough detail here to determine what you tested and what the results were, and I don't think this patch has any chance at all of getting committed without that. Please clarify. If there's some real-world test where this probe costs 0.3%-0.4%, I think that is sufficient grounds for rejecting this patch. I understand the desire of people to be able to use dtrace, but our performance is too hard-won for me to want to give any measurable of it up for tracing and instrumentation hooks that will only be used by a small number of users in a small number of situations. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
