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.

• Why does SarCheck tell me that my fast new disks are slow?
• Should I implement recommendations which only show up occasionally?
• Every time I make changes based on SarCheck’s recommendations, it makes more recommendations. Why doesn't it just figure out the correct values for all the parameters?
• When I try to run sarcheck, I get the message “sarcheck: not found”. What’s wrong?
• When I run sarcheck, I get the garbled message “The value of acctresume was Peak resource utilization statistics can be used...” What’s wrong?
• Will SarCheck work with HP-UX 11?
• Does SarCheck work on the new superdome systems?
• Why do I get the odd message "sar: Starting time must be more than ending time" with HP-UX 11.00?
• After an upgrade to HP-UX 11, why can't SarCheck figure out how much memory my system has?
• Why did SarCheck stop producting reports?
• Why does the analyze9000 program produce the error message "crt0: ERROR couldn't open dld.sl errno:000000002" ?
• How do I change the starting and ending times of the period being analyzed?
• Back to the SarCheck home page

Frequently Asked Questions (FAQ):

Q1. Why does SarCheck tell me that my fast new disks are slow?

A1. 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 cached

Another problem is that the drivers for aftermarket disk devices may not work correctly with sar. One beta 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.

Q2. Should I implement recommendations which only show up occasionally?

A2. 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”.

Q3. Every time I make changes based on SarCheck’s recommendations, it makes more recommendations. Why doesn't it just figure out the correct values for all the parameters?

A3. That’s 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.

Q4. When I try to run sarcheck, I get the message “sarcheck: not found”. What’s wrong?

A4. Check the following:

• Are you root?
• Does the sarcheck script really exist? (look for /usr/local/bin/sarcheck).
• Is /usr/local/bin in your PATH variable? (echo $PATH)

Q5. When I run sarcheck, I get the garbled message “The value of acctresume was Peak resource utilization statistics can be used...” What’s wrong?

A5. This is an old bug that has been fixed. The bug occurred in versions prior to 2.08 and it caused a garbled message to print if the values of the msgssz and msgseg parameters exceed 128k when multiplied together. Thanks to Dave Venus for reporting this bug.

Q6. Will SarCheck work with HP-UX 11?

A6. Yes. Version 3.00 was certified for HP-UX 11.00 a long time ago and it currently works fine with 11i.

Q7. Does SarCheck work on the new superdome systems?

A7. Yes. The current version of SarCheck works on all 32- and 64-bit hardware and HP-UX 11 operating systems.

Q8. Why do I get the odd message "sar: Starting time must be more than ending time" with HP-UX 11.00?

A8. This is caused by a bug in sar, and HP reports that a patch is on the way. (sorry, we don't have any details yet) There is a problem with sar's ability to process starting times with 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.

Q9: After an upgrade to HP-UX 11, why can't SarCheck figure out how much memory my system has?

A9. You should only have this problem analyzing pre-HP-UX 11 reports. The reason for this problem is that SarCheck gets most of its information from the sar report, and then gets some supplimentary data from the kernel. Since SarCheck is expecting kernel data to reside in specific locations based on the operating system version specificed in the sar report, it will be unable to find the system's memory size. We don't recommend analyzing data from one operating system on another, or analyzing data from one machine on another for this reason. If you're getting this problem when analyzing HP-UX 11 sar reports on HP-UX 11, please let us know.

Q11. Why did SarCheck stop producting reports?

A11. There are two common causes of this:

1. The software has expired. Run '/usr/local/bin/analyze9000' and look for the expiration date at the bottom of the usage text. If you've licensed SarCheck and the expiration date doesn't make sense to you, run 'analyze -s' and send us the output.
2. The kernel was rebuilt, but the system was not rebooted. After the kernel is rebuilt (frequently to implement a change recommended by SarCheck), sar may have trouble until the system is rebooted. SarCheck can't produce reports if sar isn't working..

Q12: Why does the analyze9000 program produce the error message crt0: ERROR couldn't open dld.sl errno:000000002 ?

A12. This error message is caused by the analyze9000 program looking for dld.sl in /lib. In newer operating systems it is located in /usr/lib and this error message occasionally occurs when the operating system is upgraded. We're told that the fix is in the release notes, and more information can be found by searching for dld.sl in DejaNews.

Q14. How do I change the starting and ending times of the period being analyzed?

A14. This answer assumes that you know a little about shell scripts and how to edit them.

If you run 'sarcheck', you'll have to edit the sarcheck script. Edit /usr/local/bin/sarcheck, changing the values of the ST (start time) and EN (end time) variables. Pick starting and ending times that are the times of day when you're most concerned about performance. Be careful not to include the times of the day when you perform backups, because backup activity is not like most user activity and recommendations will not be optimized for the load put on the system by production activity.

If you use the 'analyze9000' program to produce SarCheck reports in the /var/adm/sa directory, you'll have to edit the crontab entry which runs /usr/lib/sa/sa2 , changing the -s and -e 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.