Re: [PATCH] dtrace probes for memory manager

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] dtrace probes for memory manager
Date: 2009-12-09 14:04:29
Message-ID: 1260367469.1422.38.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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(at)2ndquadrant(dot)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%.


Attachment Content-Type Size
dtrace_test.patch text/x-patch 7.3 KB
memtest.c text/x-csrc 542 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-12-09 14:07:52 Re: What happened to pl/proxy and FDW?
Previous Message Peter Eisentraut 2009-12-09 13:57:42 Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash