AIX > Administrator > Performance

It's All Relative

Platform-Specific Optimization

Most scientific and technical benchmarks achieve peak performance by tuning programs to match the hardware platform's capabilities. However, this tuned code typically doesn't represent the performance of an "off-the-shelf" scientific application compiled for more general platform use. Commercial programs are also affected by evolving hardware platforms. Today, database providers are generating code optimized for POWER5 processors. This platform-specific optimization also adds to the variability of benchmark comparisons. In other words, comparisons of systems with "older" and " newer" code don't just represent a hardware-only difference.

AIX Levels

Like all OSs, AIX is in a seemingly constant state of flux, with new versions and upgrades being developed continuously. One could classify the changes as the result of at least three categories: providing fixes, adding functionality and increasing performance. Let's ignore code fixes and focus on functionality and performance. According to Brennan and Olszewski, a good example of added functionality with performance is the CIO function added to the enhanced journaling file system (JFS) in AIX 5L v5.2.0.10. This function was designed to enhance the performance of OLTP database environments on enhanced JFSs. Now couple this data in the numerous file system types that are available to AIX and the mind-numbing array of tuning parameters available. Lastly, let's consider 32- and 64-bit kernel differences. According to Brennan and Olszewski, POWER4* processor-based systems typically deliver measurably better performance when running the 64-bit kernel. But on RS64-based systems, the 32- and 64-bit kernel tends to perform similarly, if otherwise configured identically. The availability of LPAR, an optional feature on POWER4 systems and unavailable in legacy systems, creates yet another factor to be considered when making a comparison.

"Simple" Capacity Planning?

As I stated in a previous article, "Capacity Planning 101", capacity planning involves predicting when future load levels will saturate a system. It's also used to determine the most cost-effective way of delaying system saturation. In the context of this article, the term saturation indicates that a device (e.g., CPU or disk) is approaching 100-percent utilization. Keep in mind, however, that service level agreements can be violated well before the 100-percent utilization mark. All computer systems have bottlenecks. The keys to effective capacity planning are identifying the bottleneck and making decisions based on that information. And herein lies the problem.

On many occasions, the rPerf values are used in the context of capacity planning (with minimal data). However, what's actually happening is a seat-of-the-pants sizing effort, typically based upon CPU-usage numbers from their current system translated via rPerf values to the new system.

The challenge here is that accurate computer sizing requires that the analyst know that the new server can service the entire range of predicted workloads, while staying in the "linear portion" of the response time curve.

For example, a customer has a server and has been informed that the workload is going to double. The results of these efforts can range from "the new system is too small" to "the new system is too big." Many causes are possible for the wide scatter between predicted performance and actual performance, such as:

1. CPU isn't the bottleneck. This can be an especially painful lesson for the folks involved in database-server upgrades.

2. CPU is the bottleneck, but the processor architecture family has also changed from " old" to "new."

3. Primary application has changed and now represents an unknown variable.

4. I/O was the bottleneck (even if storage area network (SAN)-attached). These can be hard to find and can include I/O bus saturation, adapter saturation, cache saturation or disk saturation.

5. Fitted memory from the "old" server to the "new" server can also increase variability if the size of the primary application's footprint (e.g., 32- to 64-bit, buffer pools, etc.) has changed.

6. Don't leave out the potential bottleneck effects of a highly used LAN.

The Results

Server sizing without appropriate computer modeling can produce mixed results. Nonetheless, using rPerf comparisons for seat-of-the-pants pSeries sizing is a common occurrence. Generally speaking, CPU-intense (e.g., WebSphere*) server sizing efforts are typically less of a challenge (and produce less disastrous results) than a large SAN-attached DB2* server sizing for one simple reason: I/O. Since the rPerf benchmark doesn't consider I/O, scaling in I/O-intensive servers can produce unpredictable results. Where is the bottleneck? From queuing theory, an upgrade path to enhanced hardware must include the bottleneck device. If not, the new system will perform at the " old" system's bottleneck transaction rate. 

1. One such exception is the 1.9 GHz POWER4+ p690. The rPerf value was calculated using only half the maximum memory and gives a "more likely customer performance" rather than a " maximum possible" performance.

Tom Farwell is a technical editor for IBM Systems Magazine, Open Systems edition. He can be reached through

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Achieving a Resilient Data Center

Implement these techniques to improve data-center resiliency.


AIO: The Fast Path to Great Performance

AIX Enhancements -- Workload Partitioning

The most exciting POWER6 enhancement, live partition mobility, allows one to migrate a running LPAR to another physical box and is designed to move running partitions from one POWER6 processor-based server to another without any application downtime whatsoever.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters