Re: MusicBrainz postgres performance issues

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: MusicBrainz postgres performance issues
Дата
Msg-id CAOR=d=2rC8dYr=tY7JQTNK+eszx2J1pRHuqYFHPbqxVDXiN1sQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MusicBrainz postgres performance issues  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: MusicBrainz postgres performance issues
Список pgsql-performance
On Sun, Mar 15, 2015 at 11:46 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2015-03-15 20:42:51 +0300, Ilya Kosmodemiansky wrote:
>> On Sun, Mar 15, 2015 at 8:20 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > On 2015-03-15 11:09:34 -0600, Scott Marlowe wrote:
>> >> shared_mem of 12G is almost always too large. I'd drop it down to ~1G or so.
>> >
>> > I think that's a outdated wisdom, i.e. not generally true.
>>
>> Quite agreed. With note, that proper configured controller with BBU is needed.
>
> That imo doesn't really have anything to do with it. The primary benefit
> of a BBU with writeback caching is accelerating (near-)synchronous
> writes. Like the WAL. But, besides influencing the default for
> wal_buffers, a larger shared_buffers doesn't change the amount of
> synchronous writes.

Here's the problem with a large shared_buffers on a machine that's
getting pushed into swap. It starts to swap BUFFERs. Once buffers
start getting swapped you're not just losing performance, that huge
shared_buffers is now working against you because what you THINK are
buffers in RAM to make things faster are in fact blocks on a hard
drive being swapped in and out during reads. It's the exact opposite
of fast. :)


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

Предыдущее
От: Ilya Kosmodemiansky
Дата:
Сообщение: Re: MusicBrainz postgres performance issues
Следующее
От: Andres Freund
Дата:
Сообщение: Re: MusicBrainz postgres performance issues