How you can monitor AIX LPAR CPU with HP Sitescope for use with HP Loadrunner?

IBM AIX (Advanced Interactive eXecutive) is a series of proprietary Unix operating systems.  AIX supports a wide variety of hardware platforms.  AIX is used is several industries and in my experience with performance testing can be difficult to monitor CPU utilisation due to how AIX shares hardware resources across LPARS and how monitoring application are setup to gather this data.  LPARS are the roughly equivalent to Virtual Machine just on much larger hardware in some cases.

The method that is outlined below is a method that can be used with out of the box resources from HP Sitescope & HP Loadrunner and it does not require any additional licensing.

This method can be adapted to any operating system that can remotely output a response from a command line interface.  The command used is LPARSTAT and the value that will be monitored is idle.   idle is calculated with the following formula.

 idle = Entitlement – ( user + sys + wait )

% idle therefore is the inverted value of the CPU utilisation. So to calculate the utilisation use this formula

LPAR % CPU utilisation = (100 – %idle)

For example
CPU utilisation =  60%  (100 – %idle (40) )

What you need:

• HP Sitescope
•  HP Loadrunner
• A SSH account that can run LPARSTAT command on the target LPAR
•  Knowledge of Regular Expressions help

I would also like to acknowledge Stas Gourevich who developed this method

---

Step 1

Logon to the machine that hosts HP Sitescope.
On the HP Sitescope machine open up a putty session to the LPAR.

---

Step 2

A screen will be generated asking to create a key

Click Yes.

---

Step 3

Then verify that you can login and then verify if your user can run the LPARSTAT command.

Close the SSH window.

---

Step 4

Next open up windows notepad on the HP Sitescope host and create a file called lparstat.txt and insert the content as displayed in the screen shot below and save it to C:\sitescope\scripts.remote.

---

Step 5

Next setup a unix remote server connection to the target LPAR (example below).

---

Step 6

Next create a script monitor in HP Sitescope.

Fill out the following fields

In the label field insert the labels like so

user,sys,wait,idle,physc,entc,lbusy,vcsw,phint

In the Match expression field use this forumla for the label above however best to use the regex tool to verify that you are collecting the data you want.

/([0-9\.]+)\s+([0-9\.]+)\s+([0-9\.]+)\s+([0-9\.]+)\s+([0-9\.]+)\s+([0-9\.]+)\s+([0-9\.]+)\s+([0-9\.]+)\s+([0-9\.]+)\s+/

There are two values at the end of the LPARSTAT return post that are missing but this will still pick up the CPU Value of idle.

In the remote script command file select lparstat.txt which is the file you created earlier.

I run this monitor once per minute for a 2-hour test, I have not checked if it impacts performance at a more frequent level.  (If you run it more frequently please put the frequency you reached in the comments below)

Then click on verify and save and a screen like this.

Click OK

Then add the HP Sitescope monitor to your Loadrunner scenario, again please double check that your labels are correctly defined and remember the value is inverted that you observe so a high number is good and a low number is bad.

---

The value that I use to measure CPU is % idle, below is the description from IBM

So I will leave it to you to decide if this works in your context

http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.cmds3/lparstat.htm

%idle

Indicates the percentage of the entitled processing capacity unused while the partition was idle and did not have any outstanding disk I/O request.
For dedicated partitions, the entitled processing capacity is the number of physical processors.
For uncapped partitions with a current physical processor consumption above their entitled capacity, the percentage becomes relative to the number of physical processor consumed (physc).

Also please note that I am not a AIX expert and I know there is a lot of debate about CPU on LPARS and the best way to measure but I found that this is the best way to track CPU for my context.