This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: per-entity statistics
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Martin Peschke <mp3 at de dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: 11 Jan 2006 12:45:50 -0500
- Subject: Re: per-entity statistics
- References: <43C5154C.7080106@de.ibm.com>
Martin Peschke <mp3@de.ibm.com> writes:
> [...] First, certain data, like request latencies, is most useful
> if being provided per device, or per LUN respectively, I guess.
> [...] I could imagine an array in order to be able to store data for
> each LUN separately. Would this approach work if I want to maintain
> more than a single counter per LUN?
> Looks like going this path might result in an array of arrays, say,
> an array of latency histograms. Is this feasible?
Systemtap arrays, like those in awk, are indexed by a tuple of key
values. You can use device numbers, lun numbers, names, in any
consistent combination for each array. Each array value can be either
a string, number, or statistics.
If you need to track statistics on more than one level of grouping at
a time, then use two or more arrays, with a different set of keys.
> Would it be better to maintain separate global variables for each
> LUN? Something like:
>
> global latencies_lun1
> global latencies_lun2
> global latencies_lun3
That's not how I'd do it. Instead, something like:
##### scsi-latencies.stp
global lun_latencies # [lun:number]
global devlun_latencies # [dev:number, lun:number]
probe scsi.latencies = kernel.function("....") {
if (! scsi_lun_selected ($lun)) next
lat = EXPR
lun_latencies[$lun] <<< lat
devlun_latencies[$dev,$lun] <<< lat
}
probe end {
# report?
}
##### scsi-latencies-selected.stp
function scsi_lun_selected(id) { return 1 }
> [...] Assuming I want to measure 3 LUNs attached through adapter A
> [...] I guess, my probe would need to check everytime it has fired
> whether it's being active for a LUN to be measured before
> continueing.
That's right.
> [...] Besides, is there a good way to pass LUN selections to a
> systemtap script? [...]
We don't yet support the equivalent of command line arguments, so the
script would indeed have to be modified. However, if one structures
the overall script into a few parts like above, one them could contain
only the default lun-selection function. The end-user could override
that function only using an invocation like this:
stap -I scsi-tapset/ -e '
function scsi_lun_selected(id) { return id==1 }
probe scsi.latencies {}
'
- FChE