Date: Wed, 18 Apr 2007 13:07:59 -0500
From: "Jim C. Nasby" <jim@nasby.net>
To: Erik Jones <erik@myemma.com>
Cc: Mark Lewis <mark.lewis@mir3.com>,
	Xiaoning Ding <dingxn@cse.ohio-state.edu>, pgsql-performance@postgresql.org
Subject: Re: a question about Direct I/O and double buffering
Message-ID: <20070418180758.GW72669@nasby.net>
References: <46152D5D.5030602@cse.ohio-state.edu>
	<4C4C834E-9304-4E23-AD15-1756921500B5@myemma.com>
	<1175797629.5581.39.camel@archimedes>
	<7B476592-606F-46F0-A643-9C4E5D85CE6E@myemma.com>
	<1175802972.5581.56.camel@archimedes>
	<CE3B7895-88D9-4CEC-A9EC-506AD4533300@myemma.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CE3B7895-88D9-4CEC-A9EC-506AD4533300@myemma.com>
User-Agent: Mutt/1.5.13 (2006-08-11)

On Thu, Apr 05, 2007 at 03:10:43PM -0500, Erik Jones wrote:
> Nope.  What we never tracked down was the factor of 10 drop in  
> database transactions, not disk transactions.  The write volume was  
> most definitely due to the direct io setting -- writes are now being  
> done in terms of the system's block size where as before they were  
> being done in terms of the the filesystem's cache page size (as it's  
> in virtual memory).  Basically, we do so many write transactions that  
> the fs cache was constantly paging.

Did you try decreasing the size of the cache pages? I didn't realize
that Solaris used a different size for cache pages and filesystem
blocks. Perhaps the OS was also being too aggressive with read-aheads?

My concern is that you're essentially leaving a lot of your memory
unused this way, since shared_buffers is only set to 1.6G.

BTW, did you ever increase the parameter that controls how much memory
Solaris will use for filesystem caching?
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)