Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 061CEB5DBC2 for ; Tue, 1 Nov 2011 22:42:22 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 83821-02 for ; Wed, 2 Nov 2011 01:42:11 +0000 (UTC) X-Greylist: delayed 02:00:31.09471 by SQLgrey-1.8.0-rc2 Received: from mail-gy0-f174.google.com (mail-gy0-f174.google.com [209.85.160.174]) by mail.postgresql.org (Postfix) with ESMTP id B9464B5DEAF for ; Tue, 1 Nov 2011 22:41:58 -0300 (ADT) Received: by gyb13 with SMTP id 13so7652558gyb.19 for ; Tue, 01 Nov 2011 18:41:55 -0700 (PDT) Received: by 10.100.80.7 with SMTP id d7mr176877anb.91.1320171662875; Tue, 01 Nov 2011 11:21:02 -0700 (PDT) Received: from sidon.consistentstate.com (173-164-51-9-colorado.hfc.comcastbusiness.net. [173.164.51.9]) by mx.google.com with ESMTPS id 4sm63989196ano.9.2011.11.01.11.21.01 (version=SSLv3 cipher=OTHER); Tue, 01 Nov 2011 11:21:02 -0700 (PDT) Message-ID: <4EB03821.6090408@consistentstate.com> Date: Tue, 01 Nov 2011 12:19:13 -0600 From: Brian Fehrle User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Kevin Grittner CC: pgsql-admin@postgresql.org, Kevin Kempter Subject: Re: background writer being lazy? References: <4EAF2F20.7080205@consistentstate.com> <4EAFC2CA02000025000428D2@gw.wicourts.gov> In-Reply-To: <4EAFC2CA02000025000428D2@gw.wicourts.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201111/5 X-Sequence-Number: 38599 On 11/01/2011 08:58 AM, Kevin Grittner wrote: > Brian Fehrle 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