Optimizing AIX 6.1 performance tuning

[url]http://www.ibm.com/developerworks/aix/library/au-aix6tuning/[/url]

Ken Milberg ([email]ken@unix-linux.org[/email]), President and Managing Consultant, Technology Writer, and Site Expert, Future Tech


05 Feb 2008

Just when you thought you understood performance tuning on AIX® Version 5.3, here comes AIX 6.1 on its heels to throw you a curveball. In this article, get up-to-date information on the recent changes to performance monitoring and tuning in AIX 6.1, including CPU, virtual memory, and I/O (disk and network). Many of the changes are really less about kernel innovations and more about ancillary changes, such as improving default parameters to more accurately reflect real-world data processing. Other enhancements include unique tunable documentation, restricted tunables, and various other improvements to certain subsystems. You'll learn more about a performance tuning methodology, which needs to be a part of any tuning strategy.


Introduction

AIX® 6.1 has many important innovations and improvements, including:

Virtualization—Features such as workload partitioning and Live Application Mobility
Security—Features such as encrypted file systems and trusted AIX and role-based access control (RBAC)
Availability—Features such as AIX concurrent updates and dynamic tracing
Manageability—Features such as the new Systems Director Console for AIX and Workload Partition Manager
It also has support for POWER6 performance innovations, such as advanced simultaneous multithreading (SMT), shared dedicated processors, and variable page size. It's important to fully understand which innovations and enhancements are more the reflection of the POWER6, AIX 6.1, or a combination of both. For example, purely from an operating system perspective, AIX improves on the older defaults tunables for:

vmo
ioo
aio
no
nfso
schedo
While there are some real performance enhancements in AIX 6.1, such as improvements in I/O pacing and AIX's implementation of AIO servers, there is nothing breathtakingly different. In fact, there were more performance changes made from AIX 5.1 to AIX 5.2 and 5.2 to 5.3 (including new monitoring tools, tuning tools, new tunables that changed how you set Virtual Memory Manager (VMM) settings, and concurrent I/O improvements) than you will see moving from AIX 5.3 to AIX 6.1. In AIX 6.1, all the tuning commands remain the same, except for the ones that have been taken away (I.E. and aioo), and there are no new monitoring tools either. Other changes reflect updates that were made to the utilities that reflect support for other workload partitioning innovations, including:
curt
filemon
iostat
netpmon
pprof
procmon
proctree
svmon
topas
tprof
vmstat
Workload partitions (WPARs) allow for the usage of separate virtual partitions within one AIX image. It is more of a compliment to logical partitions (LPARs) rather than a replacement to them. WPARs actually run inside of LPARs and are very similar in concept to Solaris containers. I've built WPARs in less than 15 minutes; in fact, you'll do some of your analysis inside WPARs so that you can actually view some of the updated tools that now support WPARs. Note that WPARs are only required in AIX 6.1 and a POWER6 is not necessary. Some commands also run differently or not run at all within WPARs—a few of them will be discussed where applicable. Other AIX 6.1 performance improvements include unique tunable documentation and restricted tunables.

Tuning methodology

This section summarizes a tuning methodology that you should use to tune your systems. You don't necessarily have to use this one; there are many others, but you should be working with some kind of tuning methodology or structured program.

The five-step methodology consists of:

Establishing a baseline
Stress testing and monitoring
Identification of bottleneck
Tuning bottleneck
Repeat (starting with the second step)
Let's look at the steps in more depth:

Establishing a baseline—Before you tune or even start monitoring, you must establish a baseline. The baseline is a snapshot of what the system looks when it is performing well. This baseline should not only capture performance-type statistics, but it should also document the actual configuration of your system (amount of memory, CPU, and disk). This is important, because you need to know what a system that performs well looks like prior to troubleshooting performance that users might have complained about. Doing so helps you translate the data into a service level agreement (SLA) in which the customer signs off on.
Stress testing and monitoring—Here is where you monitor and stress your systems at peak workloads. You should use several monitoring tools here to help validate your findings. The monitoring section is critical, as you cannot effectively tune anything without having an accurate historical record of what has been going on in your system, particularly during periods of stress.
Identification of bottleneck—The objective of stressing and monitoring your system is to determine the bottleneck. You cannot provide the correct medicine without the proper diagnosis. If the system is in fact CPU bound, then you can run additional tools, such as trace, curt, splat, tprof, and ps to further identify the actual processes that are causing the bottleneck.
Tuning bottleneck—After you've finally identified the bottleneck, it is time to tune it. The tuning that you do is dependent on the bottleneck, for example, CPU, virtual memory, or I/O. Some subsystems lend themselves more to active tuning, such as virtual memory and using vmo, while the "cure" for CPU-type bottlenecks is usually managing your workload more efficiently or assigning (using dynamic logical partitioning (DLPAR), uncapped partitions, or Partition Load Manager) more resources to your system.
Repeat—Time to go through this process again, starting from the second step of the process. Only by repeating your tests and consistently monitoring your systems can you determine if your tuning has really made an impact.

6.1还没邂逅过.:$