Performance Analysis and Tuning Simplified
Sample Reports Video Pricing Info Platforms Customer Reviews About Contact Home
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):

What versions of Solaris are supported by the SarCheck?

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.

Should I implement recommendations which only show up occasionally?

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

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?

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.

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

Check the following:

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

How long does it take SarCheck to perform the analysis?

SarCheck uses approximately one second of CPU time to analyze a simple sar report .

Why do I get the message "WARNING: Bad sar -b data has been detected"?

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.

I added the SUNWaccu and SUNWaccr packages, but I can't find the sa1 and sa2 scripts in the crontab entries for sys. Now what?

Uncomment or add these lines to the crontab entries for user sys:

0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

Why do I get the message "sa[0-3][0-9]: No such file or directory"?

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.

Why do I get the message "sar[0-3][0-9]: No such file or directory"?

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.

Why did SarCheck stop producting reports?

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.

Why do I get the message "/dev/ksyms is not a 32-bit kernel namelist" or "kvm_open open error"?

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.

Why do I get the message "/opt/sarcheck/bin/analyze syntax error at line 1..."?

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.

Why do I get the message "sar: malloc failed Not enough space"?

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
0,20,40 8-17 * * 1-5 /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

How do I concatenate the following files in order to produce a multiday analysis?
sar18 sar19 sar20

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

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

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.

Why don't I get any disk performance information?

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.

What version of Solaris am I running?

We've got a page on this and it says that you should run showrev. Check it out.

Return to the Solaris page
Go to the SarCheck home page

Sample ReportsVideoPricing InfoPlatformsCustomer ReviewsAboutContact

Copyright © 1996-2014 Aptitune Corporation, All rights reserved. Information in this document is subject to change without notice.
Other products and companies referred to herein are trademarks or registered trademarks of their respective companies or mark holders.