Check out this script from Bad Penguin.co.uk. This script at it’s latest version when placed in a Unix machine, collects performance statistics at desired intervals and convert them into CSV report which can be imported to a spreadsheet, database and LoadRunner Analysis to perform analyzing work. It uses standard unix utilities (iostat, vmstat, netstat and uptime) and has been tested on Linux and Solaris systems. The usage of vmstat, netstat, iostat and uptime is far more comprehensive than those used by rstatd.

Click on the link below to get a copy of the script!

performanceMonitor.sh

The script is used in two ways. One to generate statistics and two to convert to a CSV format. The below describes the command to execute.

In respond to the questions, I’ve came out with three suggestions:

1. Use a single Vuser to monitor the Unix System Resource for the duration.
2. Use BAC (Business Availabilty Center) to monitor.
3. Use “uptime” command in the Unix box and output to a log file periodically.

Let’s discussed in details each of the methods details.

[1] Use a single Vuser to monitor the Unix system resource for the duration.

This is a method to circumvent the conventional monitoring technique. You will get your graphs from Unix, however, take note that this is not all perfect. When LoadRunner completes a scenario execution (load test), it collates the results from the Load Generators (LG in short) back to the Controller at the end of the test. Say we are monitoring for 7 days, the monitoring results of these 7 days will be sent back to the Controller which may fail due to (1) the size of data being transmitted over the bandwidth and (2) the amount of resources needed to process the monitoring results sent back, inadvertently causing it to crash or hang.

[2] Use BAC to monitor

BAC and SiteScope, both from Mercury/HP will be able to achieve that. The main purpose of the above products is to monitor in a production environment and send reports or alerts depending on the configuration. There is also other monitoring products out in the market but it’s up the organization to decide what is best for them.

Take note that the monitoring principle for LoadRunner and BAC/SiteScope is the same (BAC is tapping to capabilities of SiteScope monitoring). I’ve discussed that in an article,“How does the monitoring work in LoadRunner?” previously, which you may want to explore.

[3] Use “uptime” command in the Unix box and output to a log file periodically (Unix only)

This is by far the cheapest method as you are riding on the capabilities of your current resources. Uptime provides information about the system availability since it’s last boot up. For more information of uptime, click here. Also, refer to this resource for redirection output information.

By running a cron job periodically, example every 30 min, and redirect the output to a log file, you can trace when the system was rebooted. For more information of cron job, click here. Use the following syntax in the crontab file if you are keen implementing this suggestion.

Example:
30 18 * * * uptime >> uptime.log

In most cases, rstatd is already configured and started from inet. Therefore, you should verify if the rstatd daemon is already running using rup command. The command should report various machine statistics, including rstatd configuration. Run the following command to view the machine statistics:

rup host

If you fail to retrieve and statistics, then you may need to proceed to the next step of configuring the rstatd daemon.

To configure the rstatd daemon:

1. Run the command: su root

2. Go to /etc/inetd.conf and look for the rstatd row (it begins with the word rstatd). If it is commented out (with a #), remove the comment directive, and save the file.

3. From the command line, run:

kill -1 inet_pid

where inet_pid is the pid of the inetd process. This instructs the inetd to rescan the /etc/inetd.conf file and register all daemons which are uncommented, including the rstatd daemon.

4. Run rup again.

If the command still does not indicate that the rstatd daemon is configured, contact your system administrator. (Source: LoadRunner Monitor Reference) .

Even though rstatd is easy to configure (by uncommenting the rstatd in /etc/inetd.conf). It poses a challenge in terms of port clearance for load test. This is due to the dynamic ports that is been assigned everytime rstatd is been started.

That’s to say, if inetd is been rstarted or the server is been restarted, the port for rstatd will change. And if your client is one that’s particular about specified port clearance, you will get a headache out of it.

There are couple of alternatives that I can proposed briefly here.

1. Monitor locally using a script that collects statistics using vmstat then import into Analysis graph.
2. Use SiteScope to monitor via SSH (which also offers more security and flexibility.

Hope you find the steps simple and things to note for configuring Unix System Resource.