Re: LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers?
От
Scott Marlowe
Тема
Re: LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers?
Дата
Msg-id
CAOR=d=3fbgRZaswj1ZAf+Gt3TtNa=ox5N0qveHTrp0oxOU1zRA@mail.gmail.com
Ответ на
LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers? (Alexander Farber)
Список
Дерево обсуждения
LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers? Alexander Farber <alexander.farber@gmail.com>
Re: LAPP server moving from 4 GB RAM to 16 GB - increase
shared_buffers? Andreas Kretschmer <akretschmer@spamfence.net>
Re: LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers? Adam Cornett <adam.cornett@gmail.com>
Re: LAPP server moving from 4 GB RAM to 16 GB - increase shared_buffers? Scott Marlowe <scott.marlowe@gmail.com>
On Tue, Oct 4, 2011 at 9:11 AM, Alexander Farber 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.
В списке pgsql-general по дате отправления