From: Scott Carey <scott@richrelevance.com>
To: Mark Kirkwood <markir@paradise.net.nz>, "pgsql-performance@postgresql.org"
	<pgsql-performance@postgresql.org>
Date: Thu, 26 Mar 2009 14:49:05 -0700
Subject: Re: Raid 10 chunksize
Thread-Topic: [PERFORM] Raid 10 chunksize
Thread-Index: Acmt2exViMN+m8x5SaygtCq23G5jlQAgsJ9M
Message-ID: <C5F14661.3C9C%scott@richrelevance.com>
In-Reply-To: <49CB047E.3090909@paradise.net.nz>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 3/25/09 9:28 PM, "Mark Kirkwood" <markir@paradise.net.nz> wrote:

> I wrote:
>> Scott Marlowe wrote:
>>=20
>>>=20
>>> Can you try changing the chunksize on the test box you're testing on
>>> to see if that helps?
>>>=20
>>> =20
>>=20
>> Yes - or I am hoping to anyway (part of posting here was to collect
>> some outside validation for the idea). Thanks for your input!
>>=20
>=20
> Rebuilt with 64K chunksize:
>=20
> transaction type: TPC-B (sort of)
> scaling factor: 100
> number of clients: 24
> number of transactions per client: 12000
> number of transactions actually processed: 288000/288000
> tps =3D 866.512162 (including connections establishing)
> tps =3D 866.651320 (excluding connections establishing)
>=20
>=20
> So 64K looks quite a bit better. I'll endeavor to try out 256K next week
> too.

Just go all the way to 1MB, md _really_ likes 1MB chunk sizes for some
reason.  Benchmarks right and left on google show this to be optimal.  My
tests with md raid 0 over hardware raid 10's ended up with that being
optimal as well.

Greg's notes on aligning partitions to the chunk are key as well.


>=20
> Mark
>=20
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org=
)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>=20