Re: [PATCH] dtrace probes for memory manager

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(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-08 20:51:52
Message-ID: 4B1EBC68.5030500@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bernd Helmle wrote:
> I've tried to benchmark this now on my (fairly slow compared to server
> hardware) MacBook and see some negative trend for those memory probes
> in pgbench. Running dozens of rounds with pgbench (scale 150, 10
> clients / 1000 transactions)
That makes for a 5.5 minute test, which is unfortunately close to the
default checkpoint period. You're going to want a pgbench configuration
that's doing thousands of operations per second to measure this overhead
I think, and let it run a bit longer. The difference you're seeing
could easily be just that that the "with probes" result had more
checkpoints happen during testing than the other one--if it got even a
single checkpoint more, that could be enough to throw results off using
the default test and such low TPS results.

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>

That will do just SELECT statements against a much smaller database
(about 160MB) and will run for 10 minutes each time.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2009-12-08 21:06:37 Re: [PATCH] dtrace probes for memory manager
Previous Message Bernd Helmle 2009-12-08 20:42:31 Re: [PATCH] dtrace probes for memory manager