From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Return of the Solaris vacuum polling problem -- anyone remember this?
Date: Wed, 18 Aug 2010 15:00:10 -0400
Message-ID: <8599.1282158010@sss.pgh.pa.us> (raw)
In-Reply-To: <4C6C2B2B.9060501@agliodbs.com>
References: <4C69827A.409@agliodbs.com>
<19969.1281986537@sss.pgh.pa.us>
<4C6C2B2B.9060501@agliodbs.com>
Josh Berkus <josh@agliodbs.com> writes:
>> What I find interesting about that trace is the large proportion of
>> writes. That appears to me to indicate that it's *not* a matter of
>> vacuum delays, or at least not just a matter of that. The process seems
>> to be getting involved in having to dump dirty buffers to disk. Perhaps
>> the background writer is malfunctioning?
> You appear to be correct in that it's write-related. Will be testing on
> what specificially is producing it.
> Note that this is one of two ostensibly duplicate servers, and the issue
> has never appeared on the other server.
On further reflection, though: since we put in the BufferAccessStrategy
code, which was in 8.3, the background writer isn't *supposed* to be
very much involved in writing pages that are dirtied by VACUUM. VACUUM
runs in a small ring of buffers and is supposed to have to clean its own
dirt most of the time. So it's wrong to blame this on the bgwriter not
holding up its end. Rather, what you need to be thinking about is how
come vacuum seems to be making lots of pages dirty on only one of these
machines.
regards, tom lane
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-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, josh@agliodbs.com
Subject: Re: Return of the Solaris vacuum polling problem -- anyone remember this?
In-Reply-To: <8599.1282158010@sss.pgh.pa.us>
* 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