From: Greg Smith <greg@2ndquadrant.com>
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
Date: Mon, 03 Jan 2011 21:13:27 -0500
Message-ID: <4D228247.9020901@2ndquadrant.com> (raw)
In-Reply-To: <EF37296944B47C40ADDCCB7BFD6289FE046EED92AB@EMASC201VS01.exchad.jpmchase.net>
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>
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
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-performance@postgresql.org
Cc: greg@2ndquadrant.com, john.w.strange@jpmchase.com
Subject: Re: Question: BlockSize > 8192 with FusionIO
In-Reply-To: <4D228247.9020901@2ndquadrant.com>
* 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