|Performance Analysis and Tuning Simplified|
|News from Tech Support - The Solaris FAQ
SarCheck will find a few bugs in the sar utility (for example, occasional negative sar -b numbers), so here's the FAQ section from the manual. These questions make up 80 percent of our support calls.
Frequently asked questions (FAQ):
SarCheck supports Solaris SPARC 8+ and Solaris x86 10+. SarCheck uses our ZoneHound product to monitor Solaris Zones because this information is not present in sar.
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:
SarCheck uses approximately one second of CPU time to analyze a simple sar report .
This is apparently caused by a bug in sar but we haven't seen it since Solaris 2.5.1. Check the sar -b statistics for negative numbers. Their presence is an indication of the sar bug.
Uncomment or add these lines to the crontab entries for user sys:
0 * * * 0-6 /usr/lib/sa/sa1
This message indicates that there are no sar data files for sarcheck to analyze. The most common cause of this message is that there's a problem with the way sar is set up, or possibly the kernel was built at least 7 days ago and the system has not been rebooted since then.
This message indicates that there are no sar report files for sarcheck to analyze. The most common cause of this message is that there's a problem with the way sar is set up, or possibly the system is shut down at night before the sa2 script can be run by cron.
Run 'analyze' 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.
These messages indicate that a 32-bit version of the /opt/sarcheck/bin/analyze program is trying to read a 64-bit kernel. If you only see the kvm_open error message, it's possible that you're trying to run SarCheck from a non-root account. Generally this problem indicates that you need the 64-bit version of SarCheck for Solaris SPARC. Contact us for a 64-bit version of SarCheck for Solaris SPARC.
This message indicates that you are trying to run the 64-bit version of SarCheck on a 32-bit system. Contact us for a 32-bit version of SarCheck.
This is a sar problem, not a SarCheck problem. The message usually means that cron is running the sa1 script twice instead of once. For example, if your crontab entries look like this:
0 * * * 0-6 /usr/lib/sa/sa1
The sa1 script gets run twice at 8:00 on weekday mornings, and gets run twice every hour after that until 17:00. This example was taken from an actual support call, and the problem disappeared once the second line was changed to this:
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
There are several ways. The easiest is:
cat /var/adm/sa/sar18 /var/adm/sa/sar19 /var/adm/sa/sar20 > /tmp/multisar
Other ways are
cat `ls /var/adm/sa/sar?? | egrep '1(8|9)|20'` > /tmp/multisar
or the somewhat easier to read:
cat `ls /var/adm/sa/sar?? | egrep '18|19|20'` > /tmp/multisar
The question you'll probably ask is how to concatenate any sar report which is less than 10 (or some other number) days old. To do that:
cat `/usr/bin/find /var/adm/sa \( -name 'sar*' \) -mtime -10` > /tmp/multisar
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 /opt/sarcheck/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 'analyze' 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 'analyze' 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.
Many years ago, a customer reported solving this problem on Solaris 2.6 with patch 106818-02, and we haven't seen the problem since. If you're not getting disk information in your SarCheck report and only the headers show up in the sar report, this is a sar problem and there may be a patch that can help you. Check with Oracle to find out what patch, if any, you need.