Re: [PATCH] dtrace probes for memory manager
Zdenek Kotala <zdenek.kotala@sun.com>
From: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bernd Helmle <mailings@oopsware.de>, Greg Smith <greg@2ndquadrant.com>, Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers@postgresql.org
Date: 2009-12-11T17:59:38Z
Lists: pgsql-hackers
Robert Haas píše v čt 10. 12. 2009 v 23:55 -0500: > On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala <Zdenek.Kotala@sun.com> wrote: > > > > 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. > As I mentioned I run pg_bench -c10 -t1000 and collect data from backends. collect and analyzer is similar tool to gprof. Zdenek