From: Greg Smith <gsmith@gregsmith.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Need help with 8.4 Performance Testing
Date: Mon, 8 Dec 2008 23:00:38 -0500 (EST)
Message-ID: <Pine.GSO.4.64.0812082225470.13669@westnet.com> (raw)
In-Reply-To: <b42b73150812081723qdf7f203tcba3c3660023890f@mail.gmail.com>
References: <200812071138.01215.josh@agliodbs.com>
<dcc563d10812072140q1cb257cbs8140b390759cb1a5@mail.gmail.com>
<Pine.GSO.4.64.0812081442410.5242@westnet.com>
<dcc563d10812081231y6c71601am677ba828ff0b515e@mail.gmail.com>
<Pine.GSO.4.64.0812081731510.26019@westnet.com>
<b42b73150812081723qdf7f203tcba3c3660023890f@mail.gmail.com>
On Mon, 8 Dec 2008, Merlin Moncure wrote:
> I wonder if shared_buffers has any effect on how far you can go before
> you hit the 'tipping point'.
If your operating system has any reasonable caching itself, not so much at
first. As long as the index on the account table fits in shared_buffers,
even the basic sort of caching logic an OS uses is perfectly functional
for swapping the individual pages of the account table in and out, the
main limiting factor on pgbench performance.
There is a further out tipping point I've theorized about but not really
explored: the point where even the database indexes stop fitting in
memory usefully. As you get closer to that, I'd expect that the clock
sweep algorithm used by shared_buffers should make it a bit more likely
that those important blocks would hang around usefully if you put them
there, rather than giving most of the memory to the OS to manage.
Since the data is about 7.5X as large as the indexes, that point is way
further out than the basic bottlenecks. And if you graph pgbench results
on a scale that usefully shows the results for in-memory TPS scores, you
can barely see that part of the chart a well. One day I may get to
mapping that out better, and if I do it will be interesting to see if the
balance of shared_buffers to OS cache works the way I expect. I was
waiting until I finished the pgtune program for that, that's building some
of the guts I wanted to make it easier to tweak postgresql.conf settings
programmatically in between pgbench runs.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: gsmith@gregsmith.com, mmoncure@gmail.com, scott.marlowe@gmail.com, josh@agliodbs.com
Subject: Re: Need help with 8.4 Performance Testing
In-Reply-To: <Pine.GSO.4.64.0812082225470.13669@westnet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox