Skip site navigation (1) Skip section navigation (2)

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

From: Rajesh Kumar Mallah <mallah(dot)rajesh(at)gmail(dot)com>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: Matthew Wakeling <matthew(at)flymine(dot)org>, "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-18 07:52:36
Message-ID: a97c77030902172352w1529984aq1e9f1711f1e0771d@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
the raid10 voulme was benchmarked again
taking in consideration above points

# fdisk -l /dev/sda
Disk /dev/sda: 290.9 GB, 290984034304 bytes
255 heads, 63 sectors/track, 35376 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          12       96358+  83  Linux
/dev/sda2              13        1317    10482412+  83  Linux
/dev/sda3            1318        1578     2096482+  83  Linux
/dev/sda4            1579       35376   271482435    5  Extended
/dev/sda5            1579        1839     2096451   82  Linux swap / Solaris
/dev/sda6            1840        7919    48837568+  83  Linux
/dev/sda7           29297       35376    48837600   83  Linux


CASE                     writes            reads
                              KB/s               KB/s

ext3(whole disk) 244194 ,  352093               one part whole disk
xfs(whole disk)   402352  , 547674

25ext3                 260132 , 420905                 partition only first 25%
25xfs                   404291  , 547672                (/dev/sda6)

ext3_25               227307, 348237                  partition
specifically last  25%
xfs25                   350661, 474481                  (/dev/sda7)


Effect of ReadAhead Settings
disabled,256(default) , 512,1024

xfs_ra0                 414741 ,   66144
xfs_ra256            403647,  545026                 all tests on sda6
xfs_ra512            411357,  564769
xfs_ra1024          404392,  431168

looks like 512 was the best setting for this controller

Considering these two figures
xfs25                   350661,   474481                (/dev/sda7)
25xfs                   404291  , 547672                (/dev/sda6)

looks like the beginning of the drives are  15% faster
than the ending sections , considering this is it worth
creating a special tablespace at the begining of drives

if at all done what kind of data objects  should be placed
towards begining , WAL , indexes , frequently updated tables
or sequences ?

regds
mallah.

>On Tue, Feb 17, 2009 at 9:49 PM, Scott Carey <scott(at)richrelevance(dot)com> wrote:
> 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.

same here.

>
> 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

pgsql-performance by date

Next:From: Rajesh Kumar MallahDate: 2009-02-18 07:56:15
Subject: Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
Previous:From: ivo nascimentoDate: 2009-02-18 00:43:28
Subject: Re: Call of function inside trigger much slower than explicit function call

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group