disk stripping don't gain performance
zhang yinshu
appreciated.
I setup a simple disk strip on my test box, config as below
metastat
d10: Concat/Stripe
Size: 8383104 blocks
Stripe 0: (interlace: 64 blocks)
Device Start Block Dbase
c0t1d0s0 3648 Yes
c0t3d0s0 3648 Yes
d20: Concat/Stripe
Size: 8383104 blocks
Stripe 0: (interlace: 64 blocks)
Device Start Block Dbase
c0t1d0s1 3648 Yes
c0t3d0s1 3648 Yes
d30: Concat/Stripe
Size: 8383104 blocks
Stripe 0: (interlace: 64 blocks)
Device Start Block Dbase
c0t1d0s2 3648 Yes
c0t3d0s2 3648 Yes
d40: Concat/Stripe
Size: 10369440 blocks
Stripe 0: (interlace: 64 blocks)
Device Start Block Dbase
c0t1d0s3 3648 Yes
c0t3d0s3 3648 Yes
==================================================
but the disk performance did not benifit(at lease read), below test is
dd 4G partition, on the top is stripped partition, regular partition
below it show almost same time.
# time dd if=/dev/md/dsk/d10 of=/dev/null
8383104+0 records in
8383104+0 records out
real 3:38.6
user 1:04.1
sys 2:31.5
# time dd if=/dev/dsk/c0t0d0s4 of=/dev/null
9200142+0 records in
9200142+0 records out
real 3:54.2
user 1:13.8
sys 2:38.8
#
=================
even worse, dd a file(500M) on md is slower than regular partition
# time dd if=ying.dbf of=/dev/null
1024016+0 records in
1024016+0 records out
real 38.4
user 8.0
sys 22.2
# time dd if=/usr/ying.dbf of=/dev/null
1024016+0 records in
1024016+0 records out
real 32.0
user 7.9
sys 20.0
=======================
the test box is a Ultra450, dual CPU/1G RAM
Dragan Cvetkovic
> Guys, I need help on my first stripping setup, your input is
> appreciated.
>
> I setup a simple disk strip on my test box, config as below
>
> metastat
> d10: Concat/Stripe
> Size: 8383104 blocks
> Stripe 0: (interlace: 64 blocks)
> Device Start Block Dbase
> c0t1d0s0 3648 Yes
> c0t3d0s0 3648 Yes
[snip]
> but the disk performance did not benifit(at lease read), below test is
> dd 4G partition, on the top is stripped partition, regular partition
> below it show almost same time.
Both of your disk are on the same controler (c0).
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
Greg Andrews
>Guys, I need help on my first stripping setup, your input is
>appreciated.
>
>
>but the disk performance did not benifit(at lease read), below test is
>dd 4G partition, on the top is stripped partition, regular partition
>below it show almost same time.
>
># time dd if=/dev/md/dsk/d10 of=/dev/null
>
>
>
>
Yes. Striping only provides a performance gain when data is
being read from different parts of the filesystem at the same
time. This allows the reads to come from different disks.
When you are only reading from one part of the filesystem
at a time, such as a single dd process scanning sequentially
from the start to the end of the filesystem, you won't
see any gain.
You need to read from different parts of the filesystem
simultaneously.
-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.
Darren Dunham
> Yes. Striping only provides a performance gain when data is
> being read from different parts of the filesystem at the same
> time. This allows the reads to come from different disks.
That's false. It provides a performance gain in sequential data if the
sequential throughput of a single disk is less than the sequential
throughput of the sytem and controllers used. This is often (but not
always) true.
> When you are only reading from one part of the filesystem
> at a time, such as a single dd process scanning sequentially
> from the start to the end of the filesystem, you won't
> see any gain.
> You need to read from different parts of the filesystem
> simultaneously.
Nope. That would only work if you were reading small blocks. Otherwise
the reads would require both disks. The head movement between the
portions of the filesystem would severely reduce the throughput.
Now if the disks are fast enough and the bus/system is slow enough, then
there is no benefit to the striping.
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
zhang yinshu
Thank you for your prompt, my understanding however is this, when
writing into such layout, data will be spread to different disks by
same amount of piece on each at same time, so reading data should be
the same, reading from different physical disk at the same time. Plus,
even the disks are on same bus(SCSI), performance should be better
because disk normally slower than bus. But again, this is my thought
base on hardware raid, my case here maybe another story.
I am going to test using cp instead of dd tomorrow, BTW, is there a
disk performance benchmark too avalible under Solaris?
thanks again
yinshu,
ge...@panix.com (Greg Andrews) wrote in message news:<b7279t$hov$1...@reader1.panix.com>...
Philip Brown
>>...
>># time dd if=/dev/dsk/c0t0d0s4 of=/dev/null
> [other dd examples snipped]
>
>When you are only reading from one part of the filesystem
>at a time, such as a single dd process scanning sequentially
>from the start to the end of the filesystem, you won't
>see any gain.
but if he used dd with a blocksize wider than the stripe width, there could
be a slight speed improvement.
--
http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
Organized by the author of pkg-get
[Trim the no-bots from my address to reply to me by email!]
S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
http://www.spamlaws.com/state/ca1.html
Matt White
news:slrnb9colj....@bolthole.com:
> On Wed, 9 Apr 2003 22:36:45 +0000 (UTC), ge...@panix.com wrote:
>>>...
>>># time dd if=/dev/dsk/c0t0d0s4 of=/dev/null
>>...
>> [other dd examples snipped]
>>
>>When you are only reading from one part of the filesystem
>>at a time, such as a single dd process scanning sequentially
>>from the start to the end of the filesystem, you won't
>>see any gain.
>
> but if he used dd with a blocksize wider than the stripe width, there
> could be a slight speed improvement.
>
>
>
Test with a block size double the stripe width. My thinking is that the
bus is faster than a disk can transfer. So in theory, the data is being
transfered from one stripe while the other stripe is seeking (granted
that the stripe width is large enough to keep the disk busy).
zhang yinshu
Good point. I recreate one of metadevice, referenced
http://www.pennasoft.com/articles/SolarisRAID.shtml ,
metainit d30 2 1 c0t1d0s2 1 c0t3d0s2 -i 65k
newfs -i 8192 -m 8 -C65 /dev/md/rdsk/d30
dd looks same however, the cp is faster than old metadevices,
bash-2.03# time cp ying.dbf ying1
real 1m7.271s
user 0m0.010s
sys 0m11.200s
bash-2.03# cd /u3/oradata/yinshu/
bash-2.03# time cp ying.dbf ying1
real 0m53.330s
user 0m0.030s
sys 0m10.680s
bash-2.03#