News from Tech Support - The SCO 3.2v4 and OpenServer 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):

Q1. Why do I get the message "sarcheck: not found"?

A1. Your PATH variable does not contain the /usr/local/bin directory, or the symbolic link in /usr/bin/sarcheck is not there. The cause of the message "analyze: not found" is the same.

Q2. Why do I get the message "/usr/local/bin/sarcheck: 2525 Memory fault - core dumped"?

A2. This error is typically caused by a bug in sar which is triggered when you ask the sarcheck script to analyze sar data, but you provide the name of a sar report. Note that the number which appears in the error message will vary

Q3. Why do I get the message "WARNING: Bad sar -b data has been detected"? (5.0.0 and 5.0.2 only)

A3. This is usually caused by a bug in the OpenServer Release 5 implementation of sar, and is present in releases 5.0.0 and 5.0.2. Check the sar -b statistics for negative numbers. Their presence is an indication of the sar bug.

Q4. Why do I get the message "WARNING: Bad sar -n data has been detected"? (5.0.4 and 5.0.5 only)

A4. This is because of a change in the format of the sar report that was made in OpenServer Release 5.0.4. Support for this operating system has been added to SarCheck version 3.53. Contact us or any of our resellers and distributors if you need an upgrade.

Q5. Why did SarCheck stop reporting the name of my system when I upgraded to a Pentium Pro?

A5. This is because of a change in the format of the sar report that was made to systems using the Pentium Pro. Support for this operating system begins with version 3.55 of SarCheck for SCO OpenServer Release 5, and Version 3.03 of SarCheck for SCO UNIX 3.2v4. See our "What's New" page for current versions. Contact us or any of our resellers and distributors if you need an upgrade.

Q6. Why do I get the message "lc: sa[0-3][0-9] not found: No such file or directory (error 2)"?

A6. This message indicates that there are no sar data files for sarcheck to analyze. The most common cause of this message is that on OpenServer Release 5 systems, sar has not been enabled. To enable sar, see the man page for the sar_enable command. On older systems, this means that there's a problem with the way sar is set up, or maybe the kernel was built at least 7 days ago and the system has not been rebooted.

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

A7. The speed of disks (as reported by the manufacturer) is usually better than the speed as 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.

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

A8. 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".

Q9. 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?

A9. 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 is trial and error, and gradual change is the only way to do it. Look at pages 14-18 of the OpenServer Performance Guide, or at any of the case studies in the SCO Performance Tuning Handbook.

Q10. Is SarCheck for SCO operating systems Year 2000 compliant?

A10. We believe so. We're in the Year 2000, everything is running well and no bugs were reported. For more information, see the SarCheck Year 2000 status page.

Q11. Why did SarCheck stop producing reports?

A11. There are two common causes of this:

  1. The software has expired. 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.
  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.

If you have any questions or problems, contact us!

Q12. Which SCO operating system do I have?

A12. There are a number of operating systems produced by SCO. Type the command uname -X|grep '^Rel' and use the following table to determine what operating system you're using.

  Look for this output
SCO UNIX 3.2v4 Any version starting with '3.2v4'
SCO OpenServer Rel 5 Any version starting with '3.2v5'

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

A13. 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 'analyze' program to produce SarCheck reports in the /usr/adm/sa or /var/adm/sa directories, 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.

Q14. Why was SarCheck for OpenServer cancelled?

A14. SarCheck for OpenServer was discontinued on July 1, 2004 due to a lack of demand. Demand for an OpenServer version of SarCheck was rapidly declining during 2003 and the continuation of SarCheck for OpenServer was no longer comercially viable.

Back to the SarCheck home page

Copyright © 1996-2004 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.
This page last updated on December 13, 2004.