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 <[email protected]> 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: [email protected]
> [[email protected]] On Behalf Of Rajesh Kumar Mallah
> [[email protected]]
> Sent: Tuesday, February 17, 2009 5:25 AM
> To: Matthew Wakeling
> Cc: [email protected]
> Subject: Re: [PERFORM] suggestions for postgresql setup on Dell 2950 , PERC6i
> controller
>
> On Tue, Feb 17, 2009 at 5:15 PM, Matthew Wakeling <[email protected]> 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 <[email protected]>
>>
>> --
>> Sent via pgsql-performance mailing list ([email protected])
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>
> --
> Sent via pgsql-performance mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
