Message-ID: <4BC79072.10901@agliodbs.com>
Date: Thu, 15 Apr 2010 15:17:22 -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: Alvaro Herrera <alvherre@commandprompt.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org
Subject: Re: Autovaccum with cost_delay does not complete on one
	solaris 5.10 machine
References: <4BC76C9F.1020200@agliodbs.com>
	<20100415200056.GJ7259@alvh.no-ip.org>
	<16088.1271362441@sss.pgh.pa.us>
	<20100415202405.GL7259@alvh.no-ip.org>
In-Reply-To: <20100415202405.GL7259@alvh.no-ip.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


>> pg_usleep calls select(), and some googling indicates that select() is
>> implemented as pollsys() on recent Solaris versions.  So Josh's
>> assumption that those are delay calls seems plausible.

It's certainly the behavior I'm seeing otherwise.  In "normal
operation", the number of pages read between pollsys is consistent with
the vacuum delay settings.

>>  But it shouldn't
>> be sleeping after each page with normal cost_delay parameters, should it?

Right, that's why I find this puzzling.  If the problem was easier to
reproduce it would be easier to analyze.

> Certainly not ... The only explanation would be that the cost balance
> gets over the limit very frequently.  So one of the params would have to
> be abnormally high (vacuum_cost_page_hit, vacuum_cost_page_miss,
> vacuum_cost_page_dirty).

Nope, all defaults.  And, all identical to the other server which is
behaving normally.

Honestly, I mostly posted this in hopes that some other Solaris user
would speak up to having seen the same thing.

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