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 по дате отправления: