Re: Raid 10 chunksize

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Raid 10 chunksize
Date: 2009-04-02 06:31:11
Message-ID: 49D45BAF.7050709@paradise.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Greg Smith wrote:
>
>> Yeah - with 64K chunksize I'm seeing a result more congruent with
>> yours (866 or so for 24 clients)
>
> That's good to hear. If adjusting that helped so much, you might
> consider aligning the filesystem partitions to the chunk size too; the
> partition header usually screws that up on Linux. See these two
> references for ideas:
> http://www.vmware.com/resources/techresources/608
> http://spiralbound.net/2008/06/09/creating-linux-partitions-for-clariion
>

Well I went away and did this (actually organized for for the system
folks to...). Retesting showed no appreciable difference (if anything
slower). Then I got to thinking:

For a partition created on a (hardware) raided device, sure - alignment
is very important, however in my case we are using software (md) raid -
which creates devices out of individual partitions (which are on
individual SAS disks) e.g:

md3 : active raid10 sda4[0] sdd4[3] sdc4[2] sdb4[1]
177389056 blocks 256K chunks 2 near-copies [4/4] [UUUU]

I'm thinking that alignment issues do not apply here, as md will
allocate chunks starting at the beginning of wherever sda4 (etc) begins
- so the absolute starting position of sda4 is irrelevant. Or am I
missing something?

Thanks again

Mark

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2009-04-02 08:53:23 Re: Raid 10 chunksize
Previous Message Mark Kirkwood 2009-04-02 06:19:17 Re: Raid 10 chunksize