June 01, 2011

vxperf2 Examples

1st July, 2011: GitHub is the new home of vxperf2. Download vxperf2.

Let us take a sar log which was first collected as a binary using -A and -o options and then dumped as a text database using -A and -f options. The log is almost in a text database format, with several tables in it. It has one OS-specific header and many "Average:" lines that are not of our interest because we're interested in subsets of the duration in which the logging was done, and not the entire duration.

So we first convert the log to a table using log2db.pl from the command-line or log2db module (modifySysstat subroutine) inside a Perl script. sardb is the text database file that we'll use from here onwards.

Example 1
Suppose we want a summary of CPU utilization (just %usr, %sys), load averages (ldavg-1, ldavg-5, ldavg-15), faulting (fault/s, majflt/s) and context switching (cswch/s). Our rules file would be something like:

# rules1: Rules file for Example 1.
# Any line in the rules file that does not start with a keyword is ignored.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
# End of Example 1 rules file.

We get the results from sardb and rules1 using vxperf2.pl from the command-line or vxperf2 module (parseLogFile and applyRules subroutines) inside a Perl script. In the results directory, a summary.txt (name hardcoded) is created that contains one line each for %usr, %sys, ldavg-1, ldavg-5, ldavg-15, fault/s, majflt/s and cswch/s reporting their functions (currently min, max, sum, count and average).

Example 2
I glossed over one aspect of the CPU utilization summary in the previous example, which is that -A option gave per-processor statistics as well as an "all", and we went ahead with clubbing them together. It isn't exactly a mistake in this case, but suppose we do want to separate the per-processor statistics. Our rules file would be something like:

# rules2: Rules file for Example 2.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
# End of Example 2 rules file.

There can be only one z-axis rule, and only one field for it. vxperf2 takes the field following the z-axis keyword, and divides the CPU utilization table into sub-tables, one for each distinct value of "CPU". Along with all the lines of the previous summary.txt, the new file will now contain a few additional lines each for %usr and %sys, lines corresponding to the processors and "all".

Example 3
Suppose we want a couple of graphs, one for CPU utilization and one for load averages. Our rules file would be something like:

# rules3: Rules file for Example 3.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
plot: %usr %sys
plot: ldavg-1 ldavg-5 ldavg-15
# End of Example 3 rules file.

vxperf2 takes the fields following the plot keyword on one line and plots them using Gnuplot, naming it $field1-$field2-...-$fieldn.png. As many images as there are plot keywords in the rules file are created. The CPU utilization image will have per-processor and "all" plots because of the z-axis keyword. In this particular case, however, the second image will be empty as there are no per-processor load averages. (Instead, dropping the z-axis keyword will allow plotting of load averages. A limitation.)

Example 4
In the %usr-%sys.png created in the above examples, there are per-processor %usr plots and one "all", and similarly for %sys plots. What if we are interested in timelines of only a few of the processors, or not interested in "all"? A similar question of more significance would be when looking into block device or process-level statistics. Our rules file would be something like:

# rules4: Rules file for Example 4.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
plot: %usr %sys
only: 0 all
# End of Example 4 rules file.

There can be only one only rule, and it makes sense only in the presence of a z-axis rule (z-axis has a field name and its corresponding values are a superset of only). vxperf2 this time only plots %usr and %sys corresponding to processor 0 and "all", though it summarizes for other values of CPU as well.

Example 5
It is common to start logging a few intervals before the period of interest, and to end logging a few intervals after. Suppose we want to ignore the first 10 intervals, and then we are only interested in the next 100 intervals. Our rules file would be something like:

# rules5: Rules file for Example 5.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
plot: %usr %sys
only: 0 all
offset: 10
points: 100
# End of Example 5 rules file.

vxperf2 does what it did exactly in the previous example, except that it does it over a subset starting at the 11th reading and ending at the 110th.

Simple enough?

I mentioned a couple of limitations above and there are many others, most of which I discover only when using vxperf2, and there are often workarounds to these. vxperf2 module exposes two subroutines parseLogFile and applyRules. parseLogFile parses a text database and stores it as an in-memory database. applyRules parses a rules file and applies the rules to multiple databases at once. One parseLogFile invocation per log file, followed by one applyRules invocation per rules file.

No comments:

Post a Comment