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

PG 8.3 and large shared buffer settings

From: Dan Sugalski <dan(at)sidhe(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: PG 8.3 and large shared buffer settings
Date: 2009-09-25 03:21:55
Message-ID: a06240802c6e1df54dd21@[172.16.5.2] (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-performance
Is there any practical limit to the number of shared buffers PG 8.3.7 
can handle before more becomes counter-productive? I remember the 
buffer management algorithm used to get unhappy with too many buffers 
and past a certain point performance dropped with extra memory 
pitched at Postgres.

My production DB's around 200G, and the box hosting it has 192G of 
memory on it, running a 64 bit AIX build of 8.3.7. I'm currently 
running with 15G of shared buffers, and while performance is pretty 
good, things still hit the disk more than I'd like. I can easily bump 
the shared buffer setting up to 40G or so without affecting anything 
else that matters.

The box runs other things as well as the database, so the OS buffer 
cache tends to get effectively flushed -- permanently pinning more of 
the database in memory would be an overall win for DB performance, 
assuming bad things don't happen because of buffer management. 
(Unfortunately I've only got a limited window to bounce the server, 
so I can't do too much in the way of experimentation with buffer 
sizing)
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan(at)sidhe(dot)org                         have teddy bears and even
                                       teddy bears get drunk

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2009-09-25 04:36:28
Subject: Re: PG 8.3 and large shared buffer settings
Previous:From: Josh BerkusDate: 2009-09-25 00:25:06
Subject: Re: Regarding Sequential Scans count increase each time we press refresh .

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