This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: statistics with intermediate results
- From: "Mao, Bibo" <bibo dot mao at intel dot com>
- To: "Martin Peschke" <mp3 at de dot ibm dot com>, "William Cohen" <wcohen at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Fri, 13 Jan 2006 14:33:55 +0800
- Subject: RE: statistics with intermediate results
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