Re: perf tuning for 28 cores and 252GB RAM

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: perf tuning for 28 cores and 252GB RAM
Дата
Msg-id 20190618163329.GA13693@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: perf tuning for 28 cores and 252GB RAM  (Andres Freund <andres@anarazel.de>)
Ответы Re: perf tuning for 28 cores and 252GB RAM  (Andres Freund <andres@anarazel.de>)
Список pgsql-general
Hello

On 2019-Jun-18, Andres Freund wrote:

> On 2019-06-17 19:45:41 -0400, Jeff Janes wrote:
> > If not, I would set the value small (say, 8GB) and let the OS do the
> > heavy lifting of deciding what to keep in cache.
> 
> FWIW, in my opinion this is not a good idea in most cases. E.g. linux's
> pagecache doesn't scale particularly gracefully to large amounts of
> data, and it's decisions when to evict data aren't really better than
> postgres'. And there's a significant potential for additional
> unnecessary disk writes (because the kernel will flush dirty pagecache
> buffers, and then we'll just re-issue many of those writes again).

One additional tuning point in this area is that you need to tweak the
Linux flusher so that it starts writing earlier than what it does by
default (by setting dirty_background_bytes to some reasonable value --
as I recall it normally runs on the dirty_background_ratio setting,
which means it scales up when you add RAM, which I'm not sure is really
sensible since you really care about the disk I/O write rate rather than
anything about the memory).  If you don't do that, the kernel can
accumulate lots of memory to write before starting to write it, which is
troublesome once it does.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Igor Neyman
Дата:
Сообщение: RE: Connection refused (0x0000274D/10061)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Is array_append O(n)?