Problem Solving with sar

Donald Bryson

See Sidbebar

When users complain about performance problems, sys admins may be tempted to prescribe the performance placebo of an increase in RAM. True, RAM is a very important aspect of performance health, but sometimes it has no affect. In this article, I explore the use of sar, your system's cardiac monitor, as a prelude to diagnosis and treatment of performance ailments in a SCO Open Server environment.

Many different hardware and software factors influence system performance. The clock speed of the CPU, the speed of the data bus, the size of the L1 memory, the size of the L2 memory, the amount of RAM, the access time of the hard disk, and the type of serial controllers are just a few hardware components involved. The efficiency and type of application software on the system also taints perception of system performance. A poorly tuned system running small, efficient application programs is always perceived as faster than a well-tuned system running large hogs. However, you usually have no choices with application software. The other software component of system performance, the kernel, gives you many choices that influence system performance.

The main diagnostic tools at our disposal are sar, cpusar, and mpsar. The three commands are basically the same command. However, sar reports activity on a single processor system - both cpusar and mpsar report activity on multiprocessor systems. Although I am not specifically discussing the multiprocessor versions of the command, most of the following discussion also applies to cpuser and mpsar.<>