IBM Support

Sizing with rPerf but Don't Forget the Assumptions

How To


Summary

Every one uses the rPerf relative performance numbers but it comes with assumptions that can make sizing or capacity planning your next server "sub optimal".

Objective

Nigels Banner

Steps

RS6000 picture
POWER Relative Performance (rPerf) is often used as a way to approximate the expected difference in performance between two Power Systems servers. Although rPerf is a useful tool, it is important to understand the limitations of using rPerf to provide an estimate the performance of your specific workloads in your particular environment with a new server.
Official IBM wording: 
rPerf estimates are calculated based on systems with the latest levels of AIX and other pertinent software at the time of system announcement. Actual performance will depend on application and configuration details. The IBM eServer pSeries 640 is the baseline reference system and has a value of 1.0. Although rPerf can used to compare estimated IBM UNIX commercial processing performance, actual system performance might vary and is dependent upon many factors including system hardware configuration and software design and configuration. Note the rPerf methodology used for the POWER6 processor-based systems is identical to the method used for the POWER5 processor-based systems. Variations in incremental system performance can be observed in commercial workloads due to changes in the underlying system architecture.

First, rPerf numbers, like any published benchmark, represent the best case result when the application, configuration and system resources are all optimized -- factors that are likely to not be completely optimized in your environment with your workloads. Additionally, the real world performance of a server might be affected over time by improvements or bugs in the firmware, AIX, or the application while the official rPerf is seldom changed in the Power Systems Performance Report after the initial release of the server model.

Second, rPerf numbers are expressed in terms of throughput as opposed to speed. A newer server with twice the rPerf of an older server can be able to perform twice as many transactions as the older server, but not necessarily do the same number of transactions in one half the time. This feature is because the doubling of transactions can be based on doubling the number of threads of work rather than doubling the speed of each thread. This is especially important for older, single threaded applications that cannot exploit the benefits of SMT.
Third, you need to understand that although Power Systems servers tend to scale fairly linearly, you can't make broad assumptions that additional core capacity to an LPAR on a 32 core server delivers exactly a further 1/32 of the extra performance. Particularly as you move to larger servers, the topology of the cores and memory that is used can have a large effect on the cache and memory affinity of the LPAR and thus have a significant effect on the actual performance. There are similar assumptions, if dealing with LPARs of smaller sizes than the official rPerf numbers.  The official rPerf numbers for current and older machines can be found here:
Note: rPerf covers only AIX. For IBM i workloads there is a CPW rating. For Linux on POWER, there is nothing similar.
However, many people use rPerfs as a simplistic way of preparing a guesstimate to planning new machines based on running POWER workloads for both workload migration and server consolidation.
IBM removed the Image and Article when it closed IBM DeveloperWorks and IBM Systems Magazine and forgot to save important reference articles.
Sorry about that!
There is an excellent article in a recent IBM Systems
Magazine on this subject. I would have liked to refer you to
that article rather than duplicate it here:
How to Use rPerfs for Workload Migration
and Server Consolidation.
It was here:
http://archive.ibmsystemsmag.com/aix/tipstechniques/migration/rperf_metric/
The author Charlie Cher is a well-respected technical
person that I have known for years.
If you have a copy please let Nigel Griffiths
nag@uk.ibm.com know.
Briefly:
  • Sizing by adding up old box rPerf numbers plus scaled the rating by number of CPU cores in the LPAR and scaled down based on CPU utilisation
  • Add guesstimate of new workloads
  • Add guesstimate of growth
  • Add comfort factor like the old 80:20 rule to cover peaks in work
  • Then match the rPerf requirement against a new machine or if no workload is very large a pair of machines
  • Then decide practical things like the number of CPUs and GHz, memory to match and then adapters to keep the data flowing in and out of the machine.
I have performed exercises like this in the past.   So lets talk about things you need to think about before using rPerf numbers to make sizing or performance estimates.  I call these rules my
 "Ten Golden Rules or considerations to remember while using rPerfs for sizing"
These guidelines will help you achieve the performance that you expected.
  1. Highly threaded workloads - 2 to 3 times total SMT threads in the LPAR to make full use of the POWER processor. POWER8 and POWER9 offer SMT=8.  On a 5 CPU core LPAR that is 40 SMT threads of execution so we need something like 80 or more concurrently active processes or process threads.
  2. Well-tuned system - not out of the box settings (although those drastically improved with AIX 7.2). This is normal tuning like disk queue depth, memory use, large network packets. Recent AIX versions are much better out of the box but the basics still need to be monitored and checked. The tuning settings from older machines and OS are unlikely to work perfectly.
  3. Full Spec RAM - All memory DIMM slots used and lots of random access memory.  This is the configuration used in working out rPerfs and unused DIMM slots or minimum memory will reduce performance. How much of a reduction? - it is impossible to know without a benchmark for your specific workloads.  Also high-speed adapters (disk and network) require significant memory for buffering data as it arrives. 
  4. No Disk Issues - obviously a disk bottleneck is not overcome with a newer, faster CPU.  Also no SAN bottlenecks.
  5. No Network Issues - as above and not using network speeds that are generations behind the latest "normal" speeds.
  6. Current applications: like RDBMS, middleware & web servers software levels - rPerfs on new machine use the latest software and that can contribute to performance. Running older software from the older machines on new hardware can cause a mismatch with your rPerf expectation.
  7. Latest AIX with Service Packs - like all benchmarks, the best operating system version is used to get those latest performance fixes and improvements.
  8. Large LPARs - rPerf numbers are not based on "micro-LPARs" (less than a whole CPU) or LPARs sizes of just 1 or 2 CPUs. Check the documents for the rPerf with smallest number of CPU cores for your machine, with lower numbers you are making more assumptions - particularly as you cross physical boundaries in the machine like a drawer or whole POWER chip and lower than one CPU core.
  9. Firmware is current - The firmware includes the Hypervisor and this has many performance enhancement tweaks and often based on field experience that you need working for you. Particularly, take and early opportunity to apply the first two updates after the initial release.
  10. Bug free - users have to be willing to upgrade firmware, AIX and application software, as necessary.  Downtime needs to be built in to allow the removal of problems in the above. This is why PowerHA System Mirror (HACMP) and Live Partition Mobility were developed. You have to be realistic and understand that you will need to be able to move up to later levels of software and firmware to take advantage of improvements. IBM is currently completely out of "magic pixie dust" to fix problems without changes.  Nor can IBM promise that specific updates will fix all known problems in the universe.
If you are breaking a lot of these assumptions then you may not get the performance you expected or hoped to achieve. If you are break just one or two and then only a little bit then you never know - "you might get lucky".  If you are some-where between these options then you may have to make a series of changes, upgrades or updates to achieve good performance on your new machine.  Performance tuning is always an iterative process of removing one performance bottleneck in order to reveal the next performance bottleneck. The performance capabilities of a server require systematic work to unleash the full performance potential of the underlying computing platform.
There is also a rperf shell script that estimates the rPerf for you current AIX LPAR / VM based on its size and the best official rperf numbers available for your server model.  It is not official but makes a reasonable starting point fo server consolidation.
 
But I hope this blog entry will help every one to either get it right first time or at least set realistic expectation and outline some prime areas that will need investigation to realise benefits, thanks, Nigel
 

Additional Information

Other places to find content from Nigel Griffiths IBM (retired)

Document Location

Worldwide

[{"Line of Business":{"code":"LOB08","label":"Cognitive Systems"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"","label":""}],"Platform":[{"code":"PF002","label":"AIX"}],"Version":"All Versions"},{"Line of Business":{"code":"","label":""},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"HW1W1","label":"Power -\u003EPowerLinux"},"ARM Category":[{"code":"","label":""}],"Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions"}]

Document Information

Modified date:
01 January 2024

UID

ibm11117527

Page Feedback