Re: max_connections / shared_buffers /

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: max_connections / shared_buffers /
Дата
Msg-id 1119641045.45024.73.camel@home
обсуждение исходный текст
Ответ на max_connections / shared_buffers / effective_cache_size questions  (Puddle <rotaecho@yahoo.com>)
Список pgsql-performance
> 1.) shared_buffers I see lot of reference to making
> this the size of available ram (for the DB).  However,
> I also read to make it the size of pgdata directory.

> 2.) effective_cache_size - from what I read this is
> the 'total' allowed memory for postgresql to use
> correct? So, if I am willing to allow 1GB of memory
> should I make this 1GB?

shared_buffers in your case should be about 10000. It is not taken on a
per connection basis, but is global for that cluster. Perhaps your
memory analysis tool is fooling with you?

effective_cache_size is what you want to set to the amount of ram that
you expect the kernel to use for caching the database information in
memory. PostgreSQL will not allocate this memory, but it will make
adjustments to the query execution methods (plan) chosen.

> 3.) max_connections, been trying to figure 'how' to
> determine this #.  I've read this is buffer_size+500k
> per a connection.

> ie.  128mb(buffer) + 500kb = 128.5mb per connection?

Max connections is the number of connections to the database you intend
to allow.

Shared_buffers must be of a certain minimum size to have that number of
connections, but the 10k number above should cover any reasonable
configurations.

> work_mem and max_stack_depth set to 4096
> maintenance_work_mem set to 64mb

Sort_mem and vacuum_mem became work_mem and maintenance_work_mem as
those terms better indicate what they really do.

> Thanks for any help on this.  I'm sure bombardment of
> newbies gets old :)

That's alright. We only request that once you have things figured out
that you, at your leisure, help out a few others.


--


В списке pgsql-performance по дате отправления:

Предыдущее
От: John A Meinel
Дата:
Сообщение: Re: Speed with offset clause
Следующее
От: "Greg Maples"
Дата:
Сообщение: Performance - moving from oracle to postgresql