Re: pg_stat_bgwriter - Mailing list pgsql-performance

From Jeff Janes
Subject Re: pg_stat_bgwriter
Date
Msg-id CAMkU=1ysbjU3E=dHuthWnj2XZ_t1uVu8vajQtx65WGYtZrP6ow@mail.gmail.com
Whole thread Raw
In response to pg_stat_bgwriter  (dangal <danielito.gallo@gmail.com>)
Responses Re: pg_stat_bgwriter
List 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 by date:

Previous
From: Michael Lewis
Date:
Subject: Reading explain plans- row estimates/actuals on lower nodes vs nextlevel up
Next
From: Tomas Vondra
Date:
Subject: Re: Reading explain plans- row estimates/actuals on lower nodes vsnext level up