SarCheck V5 logo


We're trying some interesting things with the graphs in SarCheck for Linux and we're seeing things in a way that we believe is fairly unique. Here are some examples of what we're seeing:

The effect of reboots on a development system: Here are two graphs that show what happened when we stopped turning off a Linux system used by a few developers. The system doesn't really have as much memory as it would like, so it tends to use swap space. When we stopped shutting it off on February 22, the system was able to figure out what needed to be in memory. You can clearly see how swap space usage increased over a period of weeks, but the swap out rate dropped to the point where it was no longer degrading performance during compiles.

The relationship between the freepages parameters and the amount of free memory: In the following graph, the values of the freepages parameters are shown on the same graph as the amount of free memory. The fact that the freepages lines are not solid in the left part of the graph shows that the system was not running all the time. Since the amount of free memory would fall until it was between freepages.high and freepages.low, the operating system was able to reclaim memory without having to get too agressive. This is to be expected on a system which had an adequate (but hardly excessive) amount of memory.

Here is another example of how the relationship between the freepages parameters and the amount of free memory. In this case, you can see how the amount of free memory is rarely much more than the value of freepages.high and frequently hovers around the value of freepages.low. The memory shortage on this system is more severe than it is in the above graph.

The fact that some CPUs on a multiprocessor system were busier than others:

In this graph, we've used a red line to show how busy each individual CPU is and a blue line to show the average. When the red is very visible, the CPU activity has not been divided evenly among the 8 processors present. We have toyed with making the line for CPU #0 a different color, but it doesn't add any useful information. The cause for the imbalance among the CPUs can't be determined by SarCheck, but it can be clearly seen.

Intelligent y-axis scaling: We have always tried to use some intelligence in the scaling of the y-axis on our graphs. Here are a few examples: the CPU graphs almost always have a maximum value of 100%, I/O graphs usually are scaled to put the peak I/O rate about 3/4 of the way up the y-axis, graphs of free memory will sometimes "zoom in" to show the relationship between free memory and the freepages parameters, and graphs of swap space usage will be scaled so that there is a relationship between the percent of swap space used and the apparent "height" of the usage. The next two graphs demonstrate this. In the first graph, swap space usage was roughtly 50 percent and the graph correctly made the usage look significant. In the second graph, only a trivial amount of swap space was in use and the graph makes this fact intuitive.

We are constantly researching the best ways to display data and intend to take what we learn and make sure that SarCheck on all platforms provides the most useful information possible.

Back to the SarCheck home page

Copyright 1997-2005 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 information is correct as of May 23, 2005 and is subject to change without notice.