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 >
