I got the following answers from these people and many many thanks:
Thomas Straandenaes, brian.G.Milnes, Gustavo Zacarias and Alan from
compaq.
I can just start with these comments. We will install in 2 weeks the
raid system
with HSZ40 and I acn then measure the performance.
Thomas Straandenaes wrote:
=====================
The performance, it depends on what you're looking for, but if you use
the
HSZ type of controllers with a large write cache, this will take the
edge
off the write problem with RAID5. RAID5 does not have a big problem with
reads, but a large cache works well for read of course. all in all
you're
down to performance requirements for your application, down to amount of
data written per minute etc. a large write cache will work wonders for
RAID5
performance if you don't thrash the write cache in the controller.
DS20/HSZ22 (Ultra Wide differential, 128MB write back cache on the
controllers) 'bonnie'-benchmarks (default 100MB write size) on a RAID5
virtual disk:
-------Sequential Output-------- ---Sequential
Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per
Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec
%CPU
DS20R5 100 21613 63.8 21139 16.9 11098 96.7 36589 99.2 286492 98.8
24225.8 98.7
same test on a RAID1 virtual disk on the same system:
-------Sequential Output-------- ---Sequential
Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per
Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec
%CPU
DS20R1 100 27881 81.3 26032 20.5 13088 99.0 36397 98.7 281991 98.6
24225.8 99.9
as you can see, there is a certain difference between RAID5 and RAID1 on
a
100MB file, but for us this is acceptable for most datatypes (excluding
Oracle redologs and similar). For file sizes larger than 150 MB, the
difference widens.
Brian G.Milnes wrote:
================
I have succesfully run RAID5 for:
low IO low cost applications
and 90% read 10% write applications.
In the former case, you just don't have the money for more storage and
pay the IO penalty. In the latter case you have mostly read and a small
amount of write. Either you have such a low write rate that you don't
care about write times, or you're using write back cache (such as the
HSZ series).
The major problem with RAID5 is the write times. If you have 4 disks
with an 8 K chunk of data on each disk each write must be a multiple
of 6 K or the disks will be read and then written to calculate the
parity.
Sometimes this will work for your application and sometimes not.
The rules of thumb are:
1) Raid 0+1 (striped mirroring) or Raid 1 (mirroring) for databases.
Raid
0+1 makes the job of the DBA simpler. Use a logical volume manager and
explicit file layout; databases on file systems can be much lower due
to UBC caching and file system write problems. Unix 5 has direct IO
to
avoid this but its rather new.
If a disk system also fails you have to go through file system recovery
and then database recover. Database
recovery by itself will always be faster and more accurate.
2) Raid 0+1 for write hot file systems such as NFS servers and Mail.
3) Thinly striped RAID5 can often be used for special purposes such as
read intensive
large writes or low write intensity applications.
4) Thicker striped RAID5 can often be used for applications such as data
warehousing or search
catalogs.
Gustavo Zacarias wrote:
==================
I can give you my numbers....
Basically an AS4100, 1GB Ram, 1 Alpha EV5/533 CPU.
Now the good part, I/O :-)
Basically an HSZ50, 128mb cache, write-thru (has battery backup) hooked
to
the host to 1 KZPSA (1 Ultra-Wide channel).
The disks.... 10x RZ1DF-VW (9 GB 7200rpm disks) + 1 TZ 89 tape (DLT4).
This is somewhat "evenly" split in... 1 SW (StorageWorks) and scsi bus
for
just the tape and a 4+4+3 config for the disks (3 buses, 3 SWs).
I made a huge RAID5 logical drive with 1 spare (9+1). Operating System
is
Tru64 4.0F (with patchkit 1), firmware is 5.5.
>From what i've seen, the read performance is pretty fast but writing
(RAID5's weakness) not much.
When i saturate the HSZ's cache (i used a simple but effective "time dd
if=/dev/zero of=/var/huge.file bs=1024k count=1024k" for example) i see
the
constant/average speed being about 1.5 MB/s (megabytes). If you don't
saturate the cache this is of course a LOT more because of the
write-thru.
I ended up somewhat dissapointed with it, even tried some other disk
configurations but didn't help much...
Alan from Compaq wrote:
==================
To find out what kind of performance you're seeing at
the moment, use iostat for the units presented by the
particular controller. There are other programs not
on the base system, but included with the Freeware CDROM
that will also allow watching I/O performance data;
collect and Monitor for example.
To see what a subsystem is capable of you may want to
construct a benchmark that you can run on a variety of
subsystems to compare them. In general RAID-5 performs
well under read-intensive loads and poorly under write
intensive loads. The writeback cache can help write
performance a lot in many loads. Sequential write loads
give the HSZ family the opportunity to use RAID-3 like
algorithms which help the performance a lot. However,
if you load is widely scattered writes there's not much
that can be done except to get more cache.
You can some subsystem, per-unit and per-backend device
performance monitoring with VTDPY on the console of the
subsystem. Many subsystems include a program called
DSTAT which can collect some performance data. There
isn't any documentation on DSTAT on the platform kits,
but I have a PDF file of a document you're interested
in using it.
Marketing capabilities are often produced with very
carefully selected I/O loads so that the advantage
of the subsystem are kept in their best light. For
example, the request rate numbers of the HSZ were
probably produced by reading the same sector or two
from the cache of the controller. Bandwidth rates
often are just the bus burst rate, which for an HSZ70
is 40 MB/sec (UltraSCSI/Wide).
Again many thanks to you all.
with regards
Kumar
Received on Wed Dec 22 1999 - 18:46:20 NZDT