Message-ID: <4C6C431B.9010406@agliodbs.com>
Date: Wed, 18 Aug 2010 13:31:23 -0700
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
	rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Return of the Solaris vacuum polling problem -- anyone
	remember this?
References: <4C69827A.409@agliodbs.com> <19969.1281986537@sss.pgh.pa.us>
	<4C6C2B2B.9060501@agliodbs.com> <8599.1282158010@sss.pgh.pa.us>
	<4C6C2E4A.1010506@agliodbs.com> <8807.1282158479@sss.pgh.pa.us>
In-Reply-To: <8807.1282158479@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


> That would explain all the writes, but it doesn't seem to explain why
> your two servers aren't behaving similarly.

Well, that's why I said "ostensibly identical".  There may in fact be
differences, not just in the databases but in some OS libs as well.
These servers have been in production for quite a while, and the owner
has a messy deployment process.

> Most likely that's the libc implementation of the select()-based sleeps
> for vacuum_cost_delay.  I'm still suspicious that the writes are eating
> more cost_delay points than you think.

Tested that.  It does look like if I increase vacuum_cost_limit to 10000
and lower vacuum_cost_page_dirty to 10, it reads 5-7 pages and writes
2-3 before each pollsys.  The math seems completely wrong on that,
though -- it should be 50 and 30 pages, or similar.  If I can, I'll test
a vacuum without cost_delay and make sure the pollsys() are connected to
the cost delay and not something else.

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com