From: Scott Carey <scott@richrelevance.com>
To: Greg Smith <greg@2ndquadrant.com>
CC: Ireneusz Pluta <ipluta@wp.pl>, "pgsql-performance@postgresql.org"
	<pgsql-performance@postgresql.org>
Date: Thu, 8 Apr 2010 20:28:27 -0700
Subject: Re: 3ware vs. MegaRAID
Thread-Topic: [PERFORM] 3ware vs. MegaRAID
Thread-Index: AcrXlOWu/YZao+GPT6WJnbwQQTEZEA==
Message-ID: <77DF4275-AF8F-4F1F-97F8-3F6401CFCE09@richrelevance.com>
References: <4BB1FAAF.7050406@wp.pl> <4BB23254.2040109@2ndquadrant.com>
	<4BBB662C.8030102@wp.pl>
	<23D26E38-9852-4EB6-9DF9-FCB2EAE1EE6C@richrelevance.com>
	<4BBD740C.7020308@2ndquadrant.com>
In-Reply-To: <4BBD740C.7020308@2ndquadrant.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On Apr 7, 2010, at 11:13 PM, Greg Smith wrote:

> Scott Carey wrote:
>> * Change the linux 'readahead' block device parameter to at least 4MB (8=
192, see blockdev --setra) -- I don't know if there is a FreeBSD equivalent=
.
>>=20
> I haven't tested them, but 3ware gives suggestions at=20
> http://www.3ware.com/kb/Article.aspx?id=3D14852 for tuning their cards=20
> properly under FreeBSD.  You cannot get good sequential read performance=
=20
> from 3ware's cards without doing something about this at the OS level;=20
> the read-ahead on the card itself is minimal and certainly a bottleneck.
>=20
> As for your comments about drives being faster at the front than the=20
> end, the zcav tool that comes with bonnie++ is a good way to plot that=20
> out, rather than having to split partitions up and do a bunch of manual=20
> testing.

There's an FIO script that does something similar.
What I'm suggesting is that if you want to test a file system (or compare i=
t to others), and you want to get consistent results then run those tests o=
n a smaller slice of the drive.   To tune a RAID card, there is not much po=
int other than trying out the fast part of the drive, if it can keep up on =
the fast part, it should be able to keep up on the slow part.  I'm would no=
t suggest splitting the drive up into chunks and doing many manual tests.

3.5" drives are a bit more than 50% the sequential throughput at the end th=
an the start.  2.5" drives are a bit less than 65% the sequential throughpu=
t at the end than the start.  I haven't seen any significant variation of t=
hat rule on any benchmark I've run, or I've seen online for 'standard' driv=
es.  Occasionally there is a drive that doesn't use all its space and is a =
bit faster at the end.

My typical practice is to use the first 70% to 80% of a large volume for th=
e main data, and use the slowest last chunk for archives and backups.

>=20
> --=20
> Greg Smith  2ndQuadrant US  Baltimore, MD
> PostgreSQL Training, Services and Support
> greg@2ndQuadrant.com   www.2ndQuadrant.us
>=20