Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Rajesh Kumar Mallah <mallah(dot)rajesh(at)gmail(dot)com>, Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
Date: 2009-02-17 16:19:23
Message-ID: BDFBB77C9E07BE4A984DAAE981D19F961ADD4C520F@EXVMBX018-1.exch018.msoutlookonline.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 the whole thing, one file system can place the file you are testing in a very different place on disk and skew results as well.

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 of an impact depends quite a bit on what kernel you're on since the readahead code has been getting better over time and requires less 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 * the number of effective spindles. The value is in blocks (512 bytes). There is documentation on the blockdev command, and here 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(at)postgresql(dot)org [pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Rajesh Kumar Mallah [mallah(dot)rajesh(at)gmail(dot)com]
Sent: Tuesday, February 17, 2009 5:25 AM
To: Matthew Wakeling
Cc: pgsql-performance(at)postgresql(dot)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(at)flymine(dot)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(at)carfax(dot)nildram(dot)co(dot)uk>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2009-02-17 17:24:58 Re: Call of function inside trigger much slower than explicit function call
Previous Message Alexander Gorban 2009-02-17 16:17:14 Call of function inside trigger much slower than explicit function call