Re: AIX V5.3 & FASTT500 PERFORMANCE TUNING

No data of a production database should be in a RAID0. Multiply the chance of failure of each disk * the number of disks. RAID_0 is useful ONLY in environments in which the data can be restored easily, and the speed is over the availability (video capture, benchmarking, and development).

Better:

1. Check the behavior of your applications in terms of reads/writes
2. Calculate the amount of space needed for your application
3. Calculate the amount of space needed to grow your application up to your next IT renovation
4. Calculate the number of I/O transactions per second desired. Then calculate the capacity the array will have (50 TPS per disk is a good start)

Then:

• If your database is mostly read-intense, RAID_5 will give you great performance and more space to use.
• If your database is write-intense, and you can afford it, use RAID_10, otherwise, use RAID_5. Only use RAID_0 if you don´t care about loosing your data.
• Sometimes, two arrays (and two LUNS) can give you better performance, if the indexes and data are separated, or if two very active tablespaces are separated. There is no improvement if the two LUNs are on the same RAID on the FAStT.
• The most of the tuning should be made at database level. Assign a generous amount to the buffers if you fell you have an I/O bottleneck. Remenber to use vmtune or it’s equivalents to reduce (in a great amount) the memory available to filesystem cache, since most modern database engines use it’s own method to cache data, and do it on the memory allocated for the engine (eg. SGA).
• Adjust the read-ahead paramenter in the FAStT, according to the expected behavior of your database.
• Adjust the read-ahead paramenter of AIX, according to the expected behavior of your database.
• There´s a lot to tunning in the process area, dedicated vs. shared an so on… out of the scope of this thread.

HC

I would consider to change the RAID 5 configuration for a RAID 0 or RAID0 +1

RAID5:
- Suitable for OLTP databases that do most reads in large blocks of data.
- Suitable for Historical databases
- Do unnecessary I/O to preserve parity check

RAID0:
- Data spread around spindles. So I/O also.
- Suitable for high intensive I/O, such OLAP databases.
- Adding disk mirroring (RAID0+1) would increase high availability, but it costs more disks.

I sugest this redbook also:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/SG245511.html

Best Regards!

Alexandre.

Hi fellow AIX friends & associates:

I have a problem that I need your help with concerning a FAStT500 (3552-1RU)
directly connected (not connected through a switch) to an 8-way RS/6000
Model M80 with 16384MB of ram running AIX V5.3 ML03 (with post-ML03 fixes).

The M80 described above is being used for DB2 OLAP V8.2 testing.  The
firmware on both the M80 and the FAStT500 is up-to-date.  There are two (2)
EMULEX LP9002L cards installed in the M80 with data fibre channel cables
connected from each LP9002L to the FAStT500 storage controller.  

There is a 1TB RAID-5 LUN presented to AIX, and cfgmgr shows the LUN as
hdisk5.  There is only one active controller (being controller A) that
fget_config -A is reporting for dac0.  

We are using Storage Manager V9.12 to manage and configure the DASD on the
FAStT500.

We are hoping to see better write performance on FAStT500 when our OLAP job
runs; the problem for me is:  Where do I begin with respect to tuning on AIX
as well as the FAStT500?  I have done AIX tuning in the past using AIX V4.x
on internal and external SSA, but I am at a loss as to fibre channel, as
well as the FAStT500.  

As for the current write performance when our OLAP jobs runs:  I can see a
maximum of 20MB/s with an average of 9MB/s.  However, when I run a "tar -cvf
. . . " on a filesystem that resides on the FAStT500 I've seen as high as
78MB/s and an avg. of 42MB/s sustained.  

Where do I start?  Any pointers?  I've read as much as I can presently
absord concerning the FAStT500 as well as the new AIX performance tuning
commands.  

I will be most happy to supply more detailed information upon request.

--
Best Regards, I Am,


Joseph Kremblas
Phone: (919) 484-3071
IBM Certified Advanced Technical Expert (CATE) - RS/6000 (pSeries) AIX
IBM Certified Specialist - RS/6000 SP AND PSSP 3.1
IBM Certified Specialist - pSeries AIX V5.1 Systems Support
IBM Certified Specialist - pSeries AIX V5.1 System Administration
IBM Certificate of Proficiency - AIX Communications
IBM Certificate of Proficiency - AIX Installation, Backup and System
Recovery
IBM Certificate of Proficiency - AIX Problem Determination
IBM Certificate of Proficiency - AIX Performance and Systems Tuning
IBM Certified Specialist - AIX V4.X Systems Support
IBM Certified Solutions Expert - MQSeries
IBM Certified Specialist - MQSeries

"Doubt is a pain too lonely to know that faith is his twin brother."

All Rights Reserved.
--

NOTICE:  This communication may contain confidential, proprietary or legally
privileged information.  It is intended only for the person(s) to whom it is
addressed.  If you are not an intended recipient, you may not use, read,
retransmit, disseminate or take any action in reliance upon it.  Please
notify Joseph Kremblas and the sender that you have received it in error and
immediately delete the entire communication, including any attachments.
Joseph Kremblas does not encrypt and cannot ensure the confidentiality or
integrity of external e-mail communications and, therefore, cannot be
responsible for any unauthorized access, disclosure, use or tampering that
may occur during transmission.   This communication is not intended to
create or modify any obligation, contract or warranty of Joseph Kremblas,
unless he, Joseph Kremblas, clearly expresses such an intent.  Joseph
Kremblas shall not be liable for the improper or incomplete transmission of
the information contained in this communication nor for any delay in its
receipt or damage to your system.  Joseph Kremblas does not guarantee that
the integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.


---------------------------------------------------------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V, which has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587, including its group companies, shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.
---------------------------------------------------------------------------