Re: Quad processor options - Mailing list pgsql-performance

From Andrew McMillan
Subject Re: Quad processor options
Date
Msg-id 1084352292.4785.37.camel@lamb.mcmillan.net.nz
Whole thread Raw
In response to Re: Quad processor options  (Paul Tuckfield <paul@tuckfield.com>)
List pgsql-performance
On Tue, 2004-05-11 at 15:46 -0700, Paul Tuckfield wrote:

> - the "cache" column shows that linux is using 2.3G for cache. (way too
> much) you generally want to give memory to postgres to keep it "close" to
> the user, not leave it unused to be claimed by linux cache (need to leave
> *some* for linux tho)
>
> My recommendations:
> - I'll bet you have a low value for shared buffers, like 10000.  On
> your 3G system you should ramp up the value to at least 1G (125000 8k buffers)
> unless something else runs on the system.   It's best to not do things too
> drastically, so if Im right and you sit at 10000 now, try going to
> 30000 then 60000 then 125000 or above.

Huh?

Doesn't this run counter to almost every piece of PostgreSQL performance
tuning advice given?

I run my own boxes with buffers set to around 10000-20000 and an
effective_cache_size = 375000 (8k pages - around 3G).

That's working well with PostgreSQL 7.4.2 under Debian "woody" (using
Oliver Elphick's backported packages from
http://people.debian.org/~elphick/debian/).

Regards,
                    Andrew.
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053,  Manners St,  Wellington
WEB: http://catalyst.net.nz/             PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201       MOB: +64(21)635-694      OFFICE: +64(4)499-2267
Q:        How much does it cost to ride the Unibus?
A:        2 bits.
-------------------------------------------------------------------------


pgsql-performance by date:

Previous
From: Paul Tuckfield
Date:
Subject: Re: Quad processor options - summary
Next
From: "Fabio Panizzutti"
Date:
Subject: R: R: Query plan on identical tables differs . Why ?