Performance Analysis and Tuning Simplified
Sample Reports Video Platforms Customer Reviews About Contact Home

Graphing with SarCheck

Note: SarCheck has been sunsetted. Thanks to everyone for their support over the last 20+ years!

Here are some examples of interesting things that we saw when we were working on the best ways to present graphs collected from Linux statistics. These graphs are old and the algorithms used by Linux have changed several times since these graphs were made:

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.

Go to the SarCheck home page



Copyright © 1996-2018 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.

SarCheck Home