sar on Linux
If the sysstat package isn't installed on your Linux system (which it generally isn't by default), you can easily grab a copy with your favorite Linux installer -- typically one of the following commands will do the job:
yum install sysstat apt-get install sysstat rpm -ivh sysstat-10.0.2-20.18.2.x86 (the package name will vary)
Use yum or apt-get if available. These commands let you sit back and watch the system figure out exactly what it needs and do the work for you. I just installed sysstat (the package that contains the sar components) on a Fedora 17 system and got a "cannot retrieve metalink for repository updates" error, but a second try and all was well.
The install should add a cron file for you as /etc/cron.d/systat. That file will contain entries like these:
# run system activity accounting tool every 10 minutes */10 * * * * root /usr/lib/sa/sa1 1 1 # generate a daily summary of process accounting at 23:53 53 23 * * * root /usr/lib/sa/sa2 -A
As you can see, this installation of sar is going to collect performance data every ten minutes -- every day of the week. Daily summaries will be prepared shortly before midnight (11:53 PM).
The sar command itself is only one component of the sysstat package. The sadc component collects performance data and stores it in a binary data file. The sa1 component that you see listed in the second line above is a wrapper for sadc that works in cron jobs.
The sa2 script gets sar to print a report in ASCII format from the binary information that sadc has stored in the /var/log/sa/sa## files where ## is the day of the month that information was collected. The daily reports will be named /var/log/sa/sar##. When you first install the sysstat package, you will see no files in /var/log/sa. Within ten minutes, you'll see your first sa## file and, at the end of the day, your first sar## file.
sar on Solaris
On Solaris systems, sar will be installed by default. To get it running, all you have to do is uncomment the bottom three lines in the crontab file belonging to the user "sys" (shown below). Using the default settings, you will collect performance data every twenty minutes during normal business hours (8:00 AM to 6:00 PM). During other hours, it runs only once an hour (first line). You have to look at the first two of the three lines to see this. The first says "run once an hour around the clock". The second says "run at 20 minutes and 40 minutes after the hour between 8:20 AM and 5:40".
At 6:05 PM, Monday through Friday, sa2 runs, preparing the daily report. The -s and -e arguments specify the start and end times for these reports. This creates the /var/log/sar## files described earlier.
#ident "@(#)sys 1.5 92/07/14 SMI" /* SVr4.0 1.2 */ # # The sys crontab should be used to do performance collection. See cron # and performance manual pages for details on startup. # #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
In general, the 20 minute level of detail will be sufficient to hightlight performance issues. Depending on what you see in the daily reports, however, you may want to go after additional detail from the daily files to pinpoint the problem more precisely. You can change your sar tasks to run more frequently if you want more detailed data to look back at after a problem is reported. You can collect performance data as often as once a minute through your crontab file, though that is probably excessive and will generate much larger data files. Something between 5 and 20 minutes is probably ideal. From the command line, you could run sar every second with command line arguments if you were inclined to do so, but you might end up causing performance issues as much as detecting them. The command itself is very lightweight, fetching performance measures from counters in the system kernel. If used as suggested, it should have virtually undetectable impact on the system it is monitoring.
How to Use
Once sar is set up and running, you can use the sar command to look at current performance measures or to extract performance data from your sa## files. The options I've mentioned are only a few out of several dozen. You can see all of the information sar collects using the -A option or be boggled by what's available to you by reading the man page for the sar command. Either way, you are likely to be impressed by how much information is available with so little effort. The only thing about sar that is difficult is figuring out how to make good use of all the data it provides.
This article is published as part of the IDG Contributor Network. Want to Join?