shared_buffers advice - Mailing list pgsql-performance

From Paul McGarry
Subject shared_buffers advice
Date
Msg-id a056b1d41003101728h2bfe964cg43bf5ef1aabae14d@mail.gmail.com
Whole thread Raw
Responses Re: shared_buffers advice  (Dave Crooke <dcrooke@gmail.com>)
Re: shared_buffers advice  (Konrad Garus <konrad.garus@gmail.com>)
Re: shared_buffers advice  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-performance
Hi there,

I'm after a little bit of advice on the shared_buffers setting (I have
read the various docs on/linked from the performance tuning wiki page,
some very helpful stuff there so thanks to those people).

I am setting up a 64bit Linux server running Postgresql 8.3, the
server has 64gigs of memory and Postgres is the only major application
running on it. (This server is to go alongside some existing 8.3
servers, we will look at 8.4/9 migration later)

I'm basically wondering how the postgresql cache (ie shared_buffers)
and the OS page_cache interact. The general advice seems to be to
assign 1/4 of RAM to shared buffers.

I don't have a good knowledge of the internals but I'm wondering if
this will effectively mean that roughly the same amount of RAM being
used for the OS page cache will be used for redundantly caching
something the Postgres is caching as well?

IE when Postgres reads something from disk it will go into both the OS
page cache and the Postgresql shared_buffers and the OS page cache
copy is unlikely to be useful for anything.

If that is the case what are the downsides to having less overlap
between the caches, IE heavily favouring one or the other, such as
allocating shared_buffers to a much larger percentage (such as 90-95%
of expected 'free' memory).

Paul

pgsql-performance by date:

Previous
From: Kees van Dieren
Date:
Subject: Strange workaround for slow query
Next
From: Paul McGarry
Date:
Subject: Re: shared_buffers advice