This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

per-entity statistics


Hi,

I am interested in SCSI related statitics. I have been looking
through available tapsets. I have got some questions and I
would appriciate your thoughts.

First, certain data, like request latencies, is most useful
if being provided per device, or per LUN respectively, I guess.
My question is what kind of systemtap variable might suit this
requirement best.

Tapsets like http://sourceware.org/ml/systemtap/2005-q3/msg00507.html
use systemtap's assoziative arrays for similar purposes.
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?

Would it be better to maintain separate global variables for
each LUN? Something like:

global latencies_lun1
global latencies_lun2
global latencies_lun3
etc.

But this would require the script, i.e. the number of global arrays,
to be adapted for each measurement. Has someone played with doing this
in an automated fashion? A number of entities as input, and out comes
an appropriate script.

This leads to my other questions, which are about selecting LUNs
one wants to do measurements for. The scripts I have come across
so far and which are capable of providing per-entity statistics,
e.g. per-process statistics, measure all entities, or all processes
respectively.

Assuming I want to measure 3 LUNs attached through adapter A, but
I don't want to strain my system measuring all the other 23 LUNs
attached through other adapters, how could I do that? 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.

I assume the LUNs to be measured would be described using some array.
Then my probe would try to match LUNs using that array.
That wouldn't buy much efficiency, would it? Any other idea?

Besides, is there a good way to pass LUN selections to a
systemtap script? Or would it be best, as mentioned above,
to regenerate a script with the selection stuff being
built in?

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]