|Performance Analysis and Tuning Simplified|
Graphing with SarCheck
SarCheck will try to use the gnuplot utility to produce graphs and can embed those graphs in its HTML output. Not only do the graphs illustrate interesting activity mentioned in the report, but in many cases the report will explain the relevance of certain graphs. Once we started adding graphs to SarCheck's reports, we realized that we're in an excellent position to generate graphs that are specific to each operating system. Many other performance tools tend to produce generic graphs that are much less useful. SarCheck generates a relatively small number of graphs, but the graphs are the ones that highlight the problems that you need to know about. We know what information you need to do your job and we won't waste your time by asking you to wade through dozens or hundreds of different graphs that require interpretation.
Several versions of Gnuplot have been released since we coded SarCheck to work with Gnuplot 3.7. Unfortunately, backward compatibility didn't seem to be a high priority with the developers and the versions all require different scripting to work well. An entry in the sarcheck_parms file will take care of this. We also have a page that discusses some of the interesting things that we're doing with the graphs made by SarCheck for Linux and we hope you'll take a look. Even thought a single SarCheck for HP-UX package works with either PA-RISC or Itanium, gnuplot seems to be a little more picky.
Here are some of the graphs that are produced by SarCheck, and they have been put on one page to show you the different statistics that SarCheck looks at on different operating systems. They're not recent, but the graphs really haven't changed. If you're having problems with SarCheck's graphing feature, see the FAQ about Graphing with SarCheck. Precompied gnuplot binaries for AIX, HP-UX PA-RISC, and Solaris SPARC are available here.
HP-UX Memory pressure: Here is a graph produced by SarCheck that shows the effects of memory pressure. The value of gpgslim (the bottom red line) frequently increased and then returned to the flat line where it equalled the value of desfree. The value of freemem (the blue line) would also dip below that of gpgslim and both of these conditions are symptoms of a memory-poor condition. This system was used from 8:00 to 11:00 and the difference between busy and idle times can be seen. After 11:00, notice how the value of freemem tried to remain above the value of lotsfree, and how the value of gpgslim never changed.
Solaris 7 Memory utilization: Here's a graph of free memory statistics collected from 8:00 - 17:00 for an entire week. Because the amount of free memory was never less than the value of lotsfree, any memory shortage was probably brief. SarCheck will also use gnuplot to graph the scan rate and this is generally considered to be the most reliable way to spot a memory shortage on Solaris 8 and 9.
AIX Memory statistics: Here is an interesting graph produced by SarCheck Version 5.00.01 for AIX. What we've done here is to combine statistics from ps -elf output and two different sar reports relating to a memory-poor condition to give you a multidimensional view of the various statistics that show a memory bottleneck. All of the information you need to spot a memory shortage has been reduced and put into one graph to make the memory-poor environment obvious. An additional graph showing the page out rate to paging space is generated to help confirm the presence of any memory shortage. We are aso adding graphs to show the relationship between minperm/numperm/maxperm,freepages/minfree/maxfree, and the relationship between the percentage of memory which is pinned and the maxpin parameter. You're going to be amazed by what you can see with SarCheck for AIX.
The -g24 switch: In SarCheck Version 6, we added a switch that you can use to reformat multiday graphs. Instead of creating one timeline on the x-axis which can be months long, we limit the x-axis to be no more than 24 hours in length and superimpose all of the data from different days on that timeline. It is a useful way to see changes in resource utilization that occur at specific times each day. The following example shows the change that you'll see when you use the -g24 switch and how it shows that something happens on the system at approximately 15:30 every day.