pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Brian Fehrle <brianf@consistentstate.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-admin@postgresql.org, Kevin Kempter <kevink@consistentstate.com>
Subject: Re: background writer being lazy?
Date: Tue, 01 Nov 2011 12:19:13 -0600
Message-ID: <4EB03821.6090408@consistentstate.com> (raw)
In-Reply-To: <4EAFC2CA02000025000428D2@gw.wicourts.gov>
References: <4EAF2F20.7080205@consistentstate.com>
	<4EAFC2CA02000025000428D2@gw.wicourts.gov>

On 11/01/2011 08:58 AM, Kevin Grittner wrote:
> Brian Fehrle<brianf@consistentstate.com>  wrote:
>
>> So my main question is, where is the issue?
>
> That's my question, too.  What problem are you trying to solve?
>
We're trying to offload dirty buffer writes from checkpoints and from 
backends (not the bgwriter) to the background writer, I believe with the 
hope that it's the same amount of disk IO, but spread out evenly rather 
than just when a checkpoint is occurring.

>> It doesn't seem (to me) that the background writer is having a
>> hard time keeping up, because there are simply tons of times where
>> it's doing nothing. So is it just not determining that it needs to
>> do anything because there are already enough 'clean buffers' ready
>> for use at any given time?
>
> Yes.  Writing dirty buffers when there are enough buffers available
> to service requests would tend to increase overall disk writes and
> degrade performance.  You don't have a problem unless you have a
> high percentage of writes from normal backends which need to flush a
> buffer in order to get one.
>
This seems to be the case, as buffers_backend is between 
checkpoint_buffers and clean_buffers from pg_stat_bgwriter.
For example, on 2011-10-19:
checkpoint buffers: 622,519
clean_buffers:  65,879
clean_max_written: 56
backend_buffers: 460,471

Am I reading these right in wanting to reduce backend_buffers and 
checkpoint_buffers?

- Brian F

>> Would increasing bgwriter_lru_multiplier to a higher value help
>> get more to be written by the bgwriter, and if so are there any
>> negative side effects I would need to consider for this?
>
> Yes.  If a buffer is written to again by PostgreSQL after it hits
> disk because your background writer was overly aggressive, you will
> hurt your overall throughput.  Now, sometimes that's worth doing to
> control latency, but you haven't described any such problem.
>
> -Kevin




view thread (5+ messages)  latest in thread

Message-ID: <4EB03821.6090408@consistentstate.com>
Permalink:  ../4EB03821.6090408@consistentstate.com/
Also on:    postgresql.org/message-id/4EB03821.6090408@consistentstate.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: brianf@consistentstate.com, Kevin.Grittner@wicourts.gov, kevink@consistentstate.com
  Subject: Re: background writer being lazy?
  In-Reply-To: <4EB03821.6090408@consistentstate.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox