The reason why is because everyone is saying RAID-5 is bad versus a
particular implementation or whatever.  The Enterprise Storage Server
(SHARK) is RAID-5 SSA under the covers.  It flies because it has controllers
on the front end that essentially eliminate the RAID-5 effect and can
actually blow away RAID-1 solutions under high sequential write
applications.  The HDS 9900 series is the same.

It is all a balance.  RAID-5 works great for some things, bad for others.
If your RAID-5 solution does any kind of parity calculation in the array it
will perform well on sequential write.  Why? Because the generally change
from RAID-5 to RAID-3 which is the fastest on write.

Now, considering this.  What does high sequential write?

        Generally, Storage Pools and the LOG.

What does high sequential read?

        Storage Pools and the DB during backup.

So, to generally say RAID-5 is bad is totally incorrect.  It depends on your
hardware.  The number of simultaneous write operations you can perform, the
speed of your disk, etc.

In the case of TSM it even depends on how your environment is setup.  Would
I use software RAID-5, heck no, the CPU overhead is astronomical and the
read back penalty on something like Windows is will just kill you because it
is a dumb RAID-5 implementation.

I hope everyone will look at what they are saying and give specific complete
configuration information in the future.

We use the ESS.  We do striping in the AIX file system, not RAID-5.
Protection is performed in the ESS.  We had some serious performance
problems in relation to other ESS applications because we did not implement
our striping correctly and our AIX system needed some serious tuning.

If you are running default AIX vmtune parameters.  You are probably
experiencing bad performance, not because of the RAID-5 implementation, but
because of the stress RAID-5 puts on the filesystem buffers in the non-comp
space and causing astronomical paging on your system.  You change to raw and
magically the problem goes away.  Why, becauase the file system usage drops
dramatically and the paging stops.


By changing to the recommendations folks kindly suggested over the past
weeks.  My database backup time went from about 3 hours down to 1 hour for
an 85GB database.  My storage pools have dramatically improved as well and I
have not corrected their striping yet.  How did I get the performance:

        maxperm set to 40
      minperm set to 10
        max page read ahead set to 256K
        bufferpool set to 256MB (memory on the machine is 2GB)
        sufficient free pages to support the max read ahead (there are rules
about this number)

Our machine is a P660-6H1,
        (4) 450MZ processors,
        2GB memory,
        2 Fibre Channel cards for the disk, 4 for the tape (1 Gbit)
        640GB of ESS disk
        14 Magstar Drives in use so far, eventually 32.
        2 Gbit Ethernet Cards.

Yes, my environment may be unique, but at least I am telling you why what I
have works well so that a generalization is not made that has no point of
reference.

Thanks Mark, you probably saved us about 55K to prevent us from buying a
much larger TSM server.  We will probably change to (6) 750mz processors and
4GB of memory, add another Gbit card, and 2 more FC Cards to a new IO frame
for the 6H1.  Your methodical approach was exactly what we needed to
understand the issues and what to do.  Our machine purrs like a kitten now.



Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180