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.
- ‹ previous
- 1
- 2



















