Re: pg_stat_bgwriter

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: pg_stat_bgwriter
Дата
Msg-id CAMkU=1ysbjU3E=dHuthWnj2XZ_t1uVu8vajQtx65WGYtZrP6ow@mail.gmail.com
обсуждение исходный текст
Ответ на pg_stat_bgwriter  (dangal <danielito.gallo@gmail.com>)
Ответы Re: pg_stat_bgwriter
Список pgsql-performance
On Mon, Oct 14, 2019 at 1:25 PM dangal <danielito.gallo@gmail.com> wrote:
Do you think it should increase bgwriter_lru_maxpages due to the value of
maxwritten_clean?

I find the background writer to be pretty unimportant these days.  If the kernel is freely accepting writes without blocking, the backends can probably write their own buffers without it being a meaningful bottleneck.  On the other hand, if the kernel is constipated, no tweaking of the background writer parameters is going to insulate the backends from that fact.  That said, I would increase bgwriter_lru_maxpages (or decrease bgwriter_delay) anyway.  It probably won't make much difference, but if it does it is more likely to help than to hurt.
 
Do you think it should increase bgwriter_lru_maxpages,
bgwriter_lru_multiplier, and decrease bgwriter_delay due to the value of
buffers_backend compared to buffers_alloc?

I don't think that that comparison is meaningful, so wouldn't make changes based on it.
 
Do you think a modification is necessary?
What values would you recommend?
thank you

If you are experiencing a problem, this is probably not the right way to investigate it.  If a particular query is slow, try EXPLAIN (ANALYZE, BUFFERS).  If lots of user-facing things are slow, try sampling "select wait_event, wait_event_type  from pg_stat_activity where backend_type='client backend';"
 

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

Предыдущее
От: Michael Lewis
Дата:
Сообщение: Reading explain plans- row estimates/actuals on lower nodes vs nextlevel up
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Reading explain plans- row estimates/actuals on lower nodes vsnext level up