|Performance Analysis and Tuning Simplified|
News from Tech Support - The HP-UX FAQ
SarCheck will find a few bugs in the sar utility, so here's the FAQ section from the manual. These questions make up 80 percent of our support calls.
Frequently Asked Questions (FAQ):
Beginning with SarCheck version 7.01.16 for HP-UX, our agent reports on its version number. We compare the agent's version number with that of the analyze9000 program and report on discrepencies. If you're analyzing old data collected with a pre-7.01.16 version of SarCheck for HP-UX, you can expect to see this message and it does not indicate a problem. If it did, the message would be preceded with "WARNING" instead of "NOTE".
The speed of disks (as reported by the manufacturer) is usually better than the speed reported by sar. Soft I/O errors, poor locality of reference, and problems with the disk controllers are frequently responsible. Unfortunately, sar doesn't give us enough information to identify the true cause or recommend a solution. If a change to the buffer cache can be useful in circumventing the problem, SarCheck will recommend it.
SarCheck uses the following thresholds when commenting on disk service time:
> 100ms Not likely to be a magnetic disk 50 - 100ms May not be a magnetic disk 25 - 50 ms Very slow 16 - 25 ms Somewhat slow 11 - 16 ms Acceptable 6 - 11 ms Relatively fast 0.1 - 6 ms Very fast, possibly solid state or cached
Another problem is that the drivers for aftermarket disk devices may not work correctly with sar. One site reported that sar was showing 15 - 30 millisecond service times for an EMC RAID array that is supposed to be faster than a solid state disk.
Feel free to try, but implement the regularly occurring recommendations first, since those will address the most frequently occurring problems. If SarCheck occasionally recommends increasing the amount of memory, you should certainly try it. On systems with some extra memory, SarCheck will be able to make additional recommendations that could not be made on systems where memory is tight.
Thats not how real performance tuning works. There are no correct values because tuning is a series of compromises between various system resources. Performance tuning involves a certain degree of trial and error, and gradual change is the only way to do it.
Check the following:
This is caused by a bug in sar. There was a problem with sar's ability to process starting times using the -s option. Since SarCheck uses sar to produce a sar report, you may encounter this bug. To fix it, make a backup copy of the script /usr/local/bin/sarcheck and then search for, and remove the -s$ST text string. If you need assistance with this, let us know.
There are two common causes of this:
Why does the analyze9000 program produce the error message crt0: ERROR couldn't open dld.sl errno:000000002?
This error message is caused by the analyze9000 program looking for dld.sl in /lib. In some operating systems it is located in /usr/lib and this error message occasionally occurs when the operating system is upgraded. We haven't seen this error since 2004 and don't expect to see it again.
You can control the starting and ending times picked by the SarCheck script with the ST and EN keywords in the sarcheck_parms file. Here is a link to the PDF Manual for the SarCheck v7 Parmsfile.
If you use the 'analyze9000' program to produce SarCheck reports, use the -st and -en switches. Here is a link to the PDF Manual for the SarCheck v7 switches
Regardless of whether you run 'sarcheck' or 'analyze9000' to produce a SarCheck report, you should collect data at consistent intervals throughout the monitoring period. By default, sar data is collected every 20 minutes between 8:00 and 18:00 on weekdays and every 60 minutes at other times. Edit the crontab entry which runs /usr/lib/sa/sa1 to make sure that the data is collected at the same intervals during the entire period you wish to analyze.
Return to the HP-UX page
Go to the SarCheck home page