Skip site navigation (1) Skip section navigation (2)

Re: shared_buffers > 284263 on OS X

From: AgentM <agentm(at)themactionfaction(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: shared_buffers > 284263 on OS X
Date: 2006-11-27 16:05:12
Message-ID: F6C394FE-1C8E-451F-974B-4E7CFC6403C4@themactionfaction.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Nov 27, 2006, at 2:23 , Brian Wipf wrote:

> On 26-Nov-06, at 11:25 PM, Jim C. Nasby wrote:
>> On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
>>> It certainly is unfortunate if Guido's right and this is an upper
>>> limit for OS X. The performance benefit of having high  
>>> shared_buffers
>>> on our mostly read database is remarkable.
>>
>> Got any data about that you can share? People have been wondering  
>> about
>> cases where drastically increasing shared_buffers makes a difference.
>
> Unfortunately, there are more differences than just the  
> shared_buffers setting in production right now; it's a completely  
> different set up, so the numbers I have to compare against aren't  
> particularly useful.
>
> When I get the chance, I will try to post data that shows the  
> benefit of having a higher value of shared_buffers for our usage  
> pattern (with all other settings being constant -- well, except  
> maybe effective_cache_size). Basically, in our current  
> configuration, we can cache all of the data we care about 99% of  
> the time in about 3GB of shared_buffers. Having shared_buffers set  
> to 512MB as it was originally, we were needlessly going to disk all  
> of the time.

There is a known unfortunate limitation on Darwin for SysV shared  
memory which, incidentally, does not afflict POSIX or mmap'd shared  
memory.

http://archives.postgresql.org/pgsql-patches/2006-02/msg00176.php

In response to

Responses

pgsql-performance by date

Next:From: Guido NeitzerDate: 2006-11-27 16:21:37
Subject: Re: shared_buffers > 284263 on OS X
Previous:From: Michael StoneDate: 2006-11-27 13:20:22
Subject: Re: Postgres server crash

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group