Re: 3ware vs. MegaRAID - Mailing list pgsql-performance

From Scott Carey
Subject Re: 3ware vs. MegaRAID
Date
Msg-id 77DF4275-AF8F-4F1F-97F8-3F6401CFCE09@richrelevance.com
Whole thread Raw
In response to Re: 3ware vs. MegaRAID  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-performance
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 (8192, see blockdev --setra) -- I don't know
ifthere is a FreeBSD equivalent. 
>>
> I haven't tested them, but 3ware gives suggestions at
> http://www.3ware.com/kb/Article.aspx?id=14852 for tuning their cards
> properly under FreeBSD.  You cannot get good sequential read performance
> from 3ware's cards without doing something about this at the OS level;
> the read-ahead on the card itself is minimal and certainly a bottleneck.
>
> As for your comments about drives being faster at the front than the
> end, the zcav tool that comes with bonnie++ is a good way to plot that
> out, rather than having to split partitions up and do a bunch of manual
> 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 it to others), and you want to get consistent
resultsthen run those tests on a smaller slice of the drive.   To tune a RAID card, there is not much point other than
tryingout 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 not 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 than the start.  2.5" drives are a bit less
than65% the sequential throughput at the end than the start.  I haven't seen any significant variation of that rule on
anybenchmark I've run, or I've seen online for 'standard' drives.  Occasionally there is a drive that doesn't use all
itsspace and is a bit faster at the end. 

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

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


pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: PostgreSQL with Zabbix - problem of newbe
Next
From: Greg Smith
Date:
Subject: Re: PostgreSQL with Zabbix - problem of newbe