statistics with intermediate results

[Mao, Bibo]

Currently systemtap is suitable for short time performance statistics. Sometimes user mainly want to get statistical raw data by sysmtemtap, and does not need analyze this data real-time. For long time running, I think it need Ping-Pong buffer, switch the buffer when relay the data into user layer by RelayFS and keep in trace on.

bibo,mao
>-----Original Message-----
>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org]
>On Behalf Of Martin Peschke
>Sent: 2006年1月13日 1:12
>To: William Cohen
>Cc: systemtap@sources.redhat.com
>Subject: Re: statistics with intermediate results
>
>William Cohen wrote:
>> Associative arrays can be used for this purpose. Use the pointer to the
>> data structure as a key for the associative array. Store start time in
>> the associative array. Then when the data structure is encountered for
>> the completion operation fetch the time from the associative array and
>> compute the elapsed time.
>>
>> How many outstanding operations are there going to be at any given time?
>
>It depends...
>
>For SCSI, there are certain limits for tagged command queueing.
>Devices may impose limits, adapters may impose limits, other layers
>and subsystems in Linux might impose limits (blocklayer?
>SCSI mid layer?).
>
>For the IBM zSeries FCP adapter driver there used to be
>(rather arbitrary) limits of 32 concurrent commands per LUN
>and 4096 concurrent commands per adapter. Experience shows that
>when running some I/O stress workloadt or benchmark, we manage
>to hit these limits easily.
>
>In short, I would expect to see up to hundreds or maybe even thousands
>of outstanding operations going to be at any given time for systems
>like database servers, that is, for systems that are likely candidates
>for a performance analysis.
>
>I am a little concerned that searching huge systemtap arrays for
>each request could be too expensive. But I don't know much about
>the bowels of the systemtap runtime.
>
>Martin