From: Merlin Moncure <mmoncure@gmail.com>
To: Scott Carey <scott@richrelevance.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Mark Kirkwood <markir@paradise.net.nz>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Raid 10 chunksize
Date: Thu, 2 Apr 2009 13:58:44 -0400
Message-ID: <b42b73150904021058v2b390b04k53aeabc58eb4e769@mail.gmail.com> (raw)
In-Reply-To: <C5EFA6F1.3B90%scott@richrelevance.com>
References: <alpine.GSO.2.01.0903250251490.13683@westnet.com>
<C5EFA6F1.3B90%scott@richrelevance.com>
On Wed, Mar 25, 2009 at 12:16 PM, Scott Carey <scott@richrelevance.com> wrote:
> On 3/25/09 1:07 AM, "Greg Smith" <gsmith@gregsmith.com> wrote:
>> On Wed, 25 Mar 2009, Mark Kirkwood wrote:
>>> I'm thinking that the raid chunksize may well be the issue.
>>
>> Why? I'm not saying you're wrong, I just don't see why that parameter
>> jumped out as a likely cause here.
>>
>
> If postgres is random reading or writing at 8k block size, and the raid
> array is set with 4k block size, then every 8k random i/o will create TWO
> disk seeks since it gets split to two disks. Effectively, iops will be cut
> in half.
I disagree. The 4k raid chunks are likely to be grouped together on
disk and read sequentially. This will only give two seeks in special
cases. Now, if the PostgreSQL block size is _smaller_ than the raid
chunk size, random writes can get expensive (especially for raid 5)
because the raid chunk has to be fully read in and written back out.
But this is mainly a theoretical problem I think.
I'm going to go out on a limb and say that for block sizes that are
within one or two 'powers of two' of each other, it doesn't matter a
whole lot. SSDs might be different, because of the 'erase' block
which might be 128k, but I bet this is dealt with in such a fashion
that you wouldn't really notice it when dealing with different block
sizes in pg.
merlin
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, scott@richrelevance.com, gsmith@gregsmith.com, markir@paradise.net.nz
Subject: Re: Raid 10 chunksize
In-Reply-To: <b42b73150904021058v2b390b04k53aeabc58eb4e769@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