Are your storage pools JFS or Raw? Did you try both? When I first
created this server (AIX 4.3.3 on an S7A), I used all raw, but did not
see that the memory was being utilized. Then I changed the storage
pools to JFS for the readahead functionality (using straight SSA disk
for those). While I have alot of page steals, I think the JFS has
helped the daily processes that read the storagpools (backup stgpool and
migration).
Andy Carlson |\ _,,,---,,_
Senior Technical Specialist ZZZzz /,`.-'`' -. ;-;;,_
BJC Health Care |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics: http://andyc.dyndns.org/animal.html
On Mon, 7 Oct 2002, Seay, Paul wrote:
> 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
>
|
