Re: [PATCH] dtrace probes for memory manager - Mailing list pgsql-hackers

From Greg Smith
Subject Re: [PATCH] dtrace probes for memory manager
Date
Msg-id 4B1EBC68.5030500@2ndquadrant.com
Whole thread Raw
In response to Re: [PATCH] dtrace probes for memory manager  (Bernd Helmle <mailings@oopsware.de>)
Responses Re: [PATCH] dtrace probes for memory manager  (Bernd Helmle <mailings@oopsware.de>)
List 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@2ndQuadrant.com  www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: [PATCH] dtrace probes for memory manager
Next
From: Bernd Helmle
Date:
Subject: Re: [PATCH] dtrace probes for memory manager