Message-ID: <4D228247.9020901@2ndquadrant.com>
Date: Mon, 03 Jan 2011 21:13:27 -0500
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: "Strange, John W" <john.w.strange@jpmchase.com>
CC: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Question: BlockSize > 8192 with FusionIO
References: <F13DEE85-D114-4761-AD4D-924F1A741ACC@inomial.com>
	<m38vzl6z17.fsf@jhcloos.com> <4D0EFC02.7040004@vmsinfo.com>
	<5509F55C-FA66-4813-89C3-B2E62F6E8F49@Nasby.net>
	<4D21F68E.9070004@vmsinfo.com>
	<EF37296944B47C40ADDCCB7BFD6289FE046EED92AB@EMASC201VS01.exchad.jpmchase.net>
In-Reply-To: 
 <EF37296944B47C40ADDCCB7BFD6289FE046EED92AB@EMASC201VS01.exchad.jpmchase.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Strange, John W wrote:
> Has anyone had a chance to recompile and try larger a larger blocksize than 8192 with pSQL 8.4.x?

While I haven't done the actual experiment you're asking about, the 
problem working against you here is how WAL data is used to protect 
against partial database writes.  See the documentation for 
full_page_writes at 
http://www.postgresql.org/docs/current/static/runtime-config-wal.html  
Because full size copies of the blocks have to get written there, 
attempts to chunk writes into larger pieces end up requiring a 
correspondingly larger volume of writes to protect against partial 
writes to those pages.  You might get a nice efficiency gain on the read 
side, but the situation when under a heavy write load (the main thing 
you have to be careful about with these SSDs) is much less clear.

I wouldn't draw any conclusions whatsoever from what fio says about 
this; it's pretty useless IMHO for simulating anything like a real 
database workload.  I don't even use that utility anymore, as I found it 
just wasted my time compared with moving straight onto something that 
tries to act to like a database application simulation.  You might try 
running pgbench with the database scale set to large enough that the 
resulting database is large relative to total system RAM instead.

P.S. Make sure you put the FusionIO drives under a heavy write load and 
power down the server hard, so you can see what happens if there's a 
real-world crash.  Recovery time to remount the drives in that situation 
is the main drawback of their design.  It does the right thing to 
protect your data as far as I know, but the recovery can be quite time 
intensive.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books