PowerEdge 2400 RAID performance

Peter Weemeeuw peter.weemeeuw at digilife.be
Thu Aug 22 03:16:00 CDT 2002


At 05:05 PM 8/21/2002 -0700, you wrote:
> > When writing files, the server has a really poor performance.
> > Also the server seems unresponsive while writing.
> > (Reading is fast.)
>
>writing is the expensive operation with raid5 (more in a bit). Have you used
>any tools to measure performance (iozone, bonnie, etc?)


Hi,

Thanks for your help.

This are the results from bonnie++ (writing 1000 MB) :

                ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
apps07        1000M    68  99  3525   4  3123   4   632  98 38044  14 373.6   4
Latency               143ms   15398ms   13648ms   30300us   49789us    1284ms

                ------Sequential Create------ --------Random Create--------
apps07              -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
%CP  /sec %CP
                  16   539  91 +++++ +++ 10030  40   564  94 +++++ 
+++  2046  91
Latency               204ms      81us     393ms     301ms      51us     508ms

>what is your io profile? small reads/writes? large ones? are you file serving
>(e.g. NFS)? do realize that fileservers usually face small random io loads 
>once
>you've a couple clients working them.

I think it doesn't matter at this point. E.g only untarring one file causes 
the system to perform poorly (it takes for example several seconds to 
change directory).

Regards,

         Peter


> > Does anyone know of any solution and would you be so kind to inform me ?
>
>if you really want raid5, then try software raid. linux's soft raid is pretty
>dang fast. If you've enough disks and fast enough cpu you should be able to
>sustain 50-70MB/s streaming writes.
>
>Mind that raid5's worst enemy. Writes which are < the stripe size of the 
>array.
>
>stripe1 [ AAAA  BBBB    CCCC    CRC ]
>To see why we need to start with how data are represented in raid5.
>
>For four disks raid5'ed together w/ 64k chunk size, one would see this layout
>(a disk is a column, a stripe is a row)
>
>
>---------------------------
>stripe1 [ data  data    data    CRC  ]
>stripe2 [ data  data    CRC     data ]
>stripe3 [ data  CRC     data    data ]
>stripe4 [ CRC   data    data    data ]
>stripe5 [ data  data    data    CRC  ]
>
>and so on.
>
>each "data" represents 64KB, yielding a stripe size of 64KB*3 = 192KB.
>
>To write 192KB (perfectly aligned with a stripe) is easy: we
>compute a CRC and throw it to disk,
>
>e.g. if we wrote 192KB worth of A...B...C... to stripe1
>we would compute a CRC for it and write:
>
>stripe1 [ AAAA  BBBB    CCCC    CRC ]
>
>However, what if we had that (above) on disk and someone changed
>one of the "C"'s to a "D". This would require us to do the following:
>
>read in stripe1. alter the data (change that one C to a D). Recompute
>the CRC, and write it all out, resulting in:
>
>stripe1 [ AAAA  BBBB    CCDC    CRC ]
>
>Which is an awful lot of work for a small write, hence why raid5 can get very
>slow under such a load, and why you really want to have either a read-mostly
>filesystem or fairly large write requests for raid5.
>
>-- craig
>
>
>
>           .-    ... . -.-. .-. . -    -- . ... ... .- --. .
>
>Craig I. Hagan     "It's a small world, but I wouldn't want to back it up"
>hagan(at)cih.com        "True hackers don't die, their ttl expires"
>         "It takes a village to raise an idiot, but an idiot can raze a 
> village"
>
>         Stop the spread of spam, use a sendmail condom!
>              http://www.cih.com/~hagan/smtpd-hacks
>
>                        In Bandwidth we trust

Peter Weemeeuw
http://www.mycgiserver.com/~peter
Registered Linux User # 224524
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20020822/36f0d308/attachment.htm


More information about the Linux-PowerEdge mailing list