From: Gregory Stark <stark@enterprisedb.com>
To: Greg Smith <gsmith@gregsmith.com>
Cc: 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: Tue, 09 Dec 2008 13:02:02 +0000
Message-ID: <87y6ypijsl.fsf@oxford.xeocode.com> (raw)
In-Reply-To: <Pine.GSO.4.64.0812082225470.13669@westnet.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>
<Pine.GSO.4.64.0812082225470.13669@westnet.com>
Greg Smith <gsmith@gregsmith.com> writes:
> 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.
I would expect higher shared_buffers to raise the curve before the first
breakpoint but after the first breakpoint make the drop steeper and deeper.
The equilibrium where the curve becomes flatter should be lower.
That is, as long as the database fits entirely in RAM having more of the
buffers be immediately in shared buffers is better. Once there's contention
for the precious cache stealing some of it for duplicated buffers will only
hurt.
> 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.
Hm, sounds logical. At that point the slow drop-off should become even
shallower and possibly become completely flat. Greater shared_buffers might
start helping again at that point.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
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: stark@enterprisedb.com, 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: <87y6ypijsl.fsf@oxford.xeocode.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