pg.ddx.io pgsql-performance@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Scott Carey <scott@richrelevance.com>
To: Scott Carey <scott@richrelevance.com>
To: Merlin Moncure <mmoncure@gmail.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:44:20 -0700
Message-ID: <C5FA71B4.41F5%scott@richrelevance.com> (raw)
In-Reply-To: <C5FA6C0F.41E8%scott@richrelevance.com>
On 4/2/09 1:20 PM, "Scott Carey" <scott@richrelevance.com> wrote:
>
> Well, raid block size can be significantly larger than postgres or file
> system block size and the performance of random reads / writes won't get
> worse with larger block sizes. This holds only for RAID 0 (or 10), parity
> is the ONLY thing that makes larger block sizes bad since there is a
> read-modify-write type operation on something the size of one block.
>
> Raid block sizes smaller than the postgres block is always bad and
> multiplies random i/o.
>
> Read a 8k postgres block in a 8MB md raid 0 block, and you read 8k from one
> disk.
> Read a 8k postgres block on a md raid 0 with 4k blocks, and you read 4k from
> two disks.
>
OK, one more thing. The 8k read In a 8MB block size raid array can generate
two reads in the following cases:
Your read is on the boundary of the blocks AND
1: your partition is not aligned with the raid blocks. This can happen if
you partition _inside_ the raid but not if you raid inside the partition
(the latter only being applicable to software raid).
OR
2: your file system block size is smaller than the postgres block size and
the file block offset is not postgres block aligned.
The likelihood of the first condition is proportional to:
(Postgres block size)/(raid block size)
Hence, for most all setups with software raid, a larger block size up to the
point where the above ratio gets sufficiently small is optimal. If the
block size gets too large, then random access is more and more likely to
bias towards one drive over the others and lower throughput.
Obviously, in the extreme case where the block size is the disk size, you
would have to randomly access 100% of all the data to get full speed.
view thread (59+ messages) latest in thread
Message-ID: <C5FA71B4.41F5%scott@richrelevance.com> Permalink: ../C5FA71B4.41F5%25scott@richrelevance.com/ Also on: postgresql.org/message-id/C5FA71B4.41F5%scott@richrelevance.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: scott@richrelevance.com, mmoncure@gmail.com, gsmith@gregsmith.com, markir@paradise.net.nz Subject: Re: Raid 10 chunksize In-Reply-To: <C5FA71B4.41F5%scott@richrelevance.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