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.
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 |