Re: feature: dynamic DB cache resizing

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: feature: dynamic DB cache resizing
Дата
Msg-id 3099.1133821073@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: feature: dynamic DB cache resizing  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: feature: dynamic DB cache resizing  ("Ed L." <pgsql-general@bluepolka.net>)
Список pgsql-general
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Ed L. wrote:
>> We have ~75 pgsql clusters running in environments where downtime
>> comes at a premium cost.  We often run multiple clusters on a
>> single box, and find it necessary to adjust the size of the
>> static DB cache as we add or move clusters.  Unfortunately, that
>> means some downtime.  It would be extremely useful in minimizing
>> downtime to be able to dynamically resize the DB cache without
>> having to restart the cluster.  How hard would that be?

> We can't think of how to do because it is all shared memory shared by
> ever forked process --- does that help explain its complexity?

There isn't any particularly good reason to be resizing shared_buffers
on the fly anyway; much easier to let the kernel adapt the size of its
disk cache instead.  Best practice for shared_buffers is to set it
somewhere in the range of 10K to 50K and forget it.

If Ed was thinking of something other than shared_buffers, he should
explain what.

            regards, tom lane

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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: EXPLAIN SELECT .. does not return
Следующее
От: Tom Lane
Дата:
Сообщение: Re: EXPLAIN SELECT .. does not return