Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller - Mailing list pgsql-performance

From Scott Carey
Subject Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
Date
Msg-id BDFBB77C9E07BE4A984DAAE981D19F961ADD4C520F@EXVMBX018-1.exch018.msoutlookonline.net
Whole thread Raw
In response to Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller  (Rajesh Kumar Mallah <mallah.rajesh@gmail.com>)
Responses Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller  (Rajesh Kumar Mallah <mallah.rajesh@gmail.com>)
List pgsql-performance
Generally speaking, you will want to use a partition that is 25% or less the size of the whole disk as well.  If it is
thewhole thing, one file system can place the file you are testing in a very different place on disk and skew results
aswell. 

My own tests, using the first 20% of an array for all, showed that xfs with default settings beat out or equalled
'tuned'settings with hardware raid 10, and was far faster than ext3 in sequential transfer rate. 

If testing STR, you will also want to tune the block device read ahead value (example: /sbin/blockdev -getra
/dev/sda6). This has very large impact on sequential transfer performance (and no impact on random access).  How large
ofan impact depends quite a bit on what kernel you're on since the readahead code has been getting better over time and
requiresless tuning.  But it still defaults out-of-the-box to more optimal settings for a single drive than RAID. 
For SAS, try 256 or 512 * the number of effective spindles (spindles * 0.5 for raid 10).  For SATA, try 1024 or 2048 *
thenumber of effective spindles.  The value is in blocks (512 bytes).  There is documentation on the blockdev command,
andhere is a little write-up I found with a couple web searches:
http://portal.itauth.com/2007/11/20/howto-linux-double-your-disk-read-performance-single-command

________________________________________
From: pgsql-performance-owner@postgresql.org [pgsql-performance-owner@postgresql.org] On Behalf Of Rajesh Kumar Mallah
[mallah.rajesh@gmail.com]
Sent: Tuesday, February 17, 2009 5:25 AM
To: Matthew Wakeling
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] suggestions for postgresql setup on Dell 2950 , PERC6i   controller

On Tue, Feb 17, 2009 at 5:15 PM, Matthew Wakeling <matthew@flymine.org> wrote:
> On Tue, 17 Feb 2009, Rajesh Kumar Mallah wrote:
>>
>> sda6 --> xfs with default formatting options.
>> sda7 --> mkfs.xfs -f  -d sunit=128,swidth=512   /dev/sda7
>> sda8 --> ext3 (default)
>>
>> it looks like mkfs.xfs  options sunit=128 and swidth=512 did not improve
>> io throughtput as such in bonnie++ tests .
>>
>> it looks like ext3 with default options performed worst in my case.
>
> Of course, doing comparisons using a setup like that (on separate
> partitions) will skew the results, because discs' performance differs
> depending on the portion of the disc being accessed. You should perform the
> different filesystem tests on the same partition one after the other
> instead.

point noted . will redo the test on ext3.


>
> Matthew
>
> --
> "We did a risk management review.  We concluded that there was no risk
> of any management."        -- Hugo Mills <hugo@carfax.nildram.co.uk>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

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

pgsql-performance by date:

Previous
From: Alexander Gorban
Date:
Subject: Call of function inside trigger much slower than explicit function call
Next
From: Robert Haas
Date:
Subject: Re: Call of function inside trigger much slower than explicit function call