pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Merlin Moncure <mmoncure@gmail.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: 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: Tue, 4 Jan 2011 11:48:59 -0500
Message-ID: <AANLkTimtMDF8GiJuEBm+k-RZNBpUdVxknuenHX=cAMNd@mail.gmail.com> (raw)
In-Reply-To: <4D228247.9020901@2ndquadrant.com>
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>
	<4D228247.9020901@2ndquadrant.com>

On Mon, Jan 3, 2011 at 9:13 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> 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.

most flash drives, especially mlc flash, use huge blocks anyways on
physical level.  the numbers claimed here
(http://www.fusionio.com/products/iodrive/)  (141k write iops) are
simply not believable without write buffering.  i didn't see any note
of how fault tolerance is maintained through the buffer (anyone
know?).

assuming they do buffer, i would expect a smaller blocksize would be
better/easier on the ssd, since this would mean less gross writing,
higher maximum throughput, and less wear and tear on the flash; the
advantages of the larger blocksize are very hardware driven and
already managed by the controller.

if they don't buffer (again, I'm very skeptical this is the case), a
larger block size, possibly even a much larger block size (like 256k)
would be an interesting test.  i'm pretty skeptical about the fusion
i/o product generally, because i don't think the sata interface is a
bottleneck save for read caching, and the o/s is already buffering
reads.  the storage medium is still the bottleneck for the most part
(even if it's much faster at certain things).   note fusion is still
useful for some things, but the nice is narrower than it looks on the
surface.

merlin



view thread (7+ messages)  latest in thread

Message-ID: <AANLkTimtMDF8GiJuEBm+k-RZNBpUdVxknuenHX=cAMNd@mail.gmail.com>
Permalink:  ../AANLkTimtMDF8GiJuEBm+k-RZNBpUdVxknuenHX=cAMNd@mail.gmail.com/
Also on:    postgresql.org/message-id/AANLkTimtMDF8GiJuEBm+k-RZNBpUdVxknuenHX=cAMNd@mail.gmail.com

 · 

reply
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: mmoncure@gmail.com, greg@2ndquadrant.com, john.w.strange@jpmchase.com
  Subject: Re: Question: BlockSize > 8192 with FusionIO
  In-Reply-To: <AANLkTimtMDF8GiJuEBm+k-RZNBpUdVxknuenHX=cAMNd@mail.gmail.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