Re: LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers?

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Alexander Farber <alexander(dot)farber(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers?
Date: 2011-10-04 15:59:36
Message-ID: CAOR=d=3fbgRZaswj1ZAf+Gt3TtNa=ox5N0qveHTrp0oxOU1zRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Oct 4, 2011 at 9:11 AM, Alexander Farber
<alexander(dot)farber(at)gmail(dot)com> wrote:
> Hello,
>
> I run a LAPP server (PostgreSQL 8.4 @ CentOS 5.7 / 64 bit;
> only 4 GB RAM) with the following config:
>
> postgresql.conf (unix socket only and - ):
>
>    max_connections = 50
>    shared_buffers = 1024MB                 # min 128kB

OK, so a lot of folks think the only way to take advantage of the
extra memory is for postgresql to directly manage and use it. this is
a rather naive view. PostgreSQL can use some of it for sorts etc,
index rebuilds and so on, in addition to using it for shared buffers.
Further the kernel uses what's not being used elsewhere for file
system caching, so often there's no real gain from having postgresql
try to cache more data when the OS is already doing it, and for large
amounts of memory, usually doing it better.

On top of that, the dirty buffers have to get written out to disk
eventually, and on a transactional system having more dirty buffers to
manage just makes things slower not faster.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2011-10-04 16:00:48 Re: table sequence, renumbering
Previous Message J.V. 2011-10-04 15:51:50 table sequence, renumbering