dtrace discuss - Jan 2006 - Known limitation?

I know I''ve asked about this message in the past:

"dtrace: processing aborted: Abort due to systemic unresponsiveness",

but what I don''t know is whether or not it is known that sending output
to the console causes this to happen rather easily and that sending the 
output to a file prevents this.

Is this documented anywhere?  Is this a bug, or just a limitation?

Since I have a script that produces a lot of data, do I need to warn 
people not to run it on the console without redirecting the output to a 
file, or will people already know not to do that?

Thanks for any/all opinions on this.

Jim

On 1/18/06, Jim Wahlig <James.Wahlig at sun.com>
wrote:
> I know I''ve asked about this message in the past:
>
> "dtrace: processing aborted: Abort due to systemic
unresponsiveness",
>
> but what I don''t know is whether or not it is known that sending
output
> to the console causes this to happen rather easily and that sending the
> output to a file prevents this.
>
> Is this documented anywhere?  Is this a bug, or just a limitation?
>
> Since I have a script that produces a lot of data, do I need to warn
> people not to run it on the console without redirecting the output to a
> file, or will people already know not to do that?
>
> Thanks for any/all opinions on this.
>
> Jim
>
wrap it in a shell script or possibly make a perl script that parses
the output and have it create a summary of the output. maybe use a
agregation in the dtrace script, if you are bogging the system down
that much, it may hide the real problem you are looking for in the
first place.


James Dickens
uadmin.blogspot.com
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>

I''m not actually looking for a problem, well, not a particular problem.
In fact, my use of dtrace may be a problem in itself.  I''m trying to
use
dtrace as an observability tool, which perhaps, isn''t the best use of 
dtrace.  The project, NFS server observability, was implemented as 
dtrace scripts that just dump raw data (and lots of it).  Post 
processors, or filters, would be used to make sense of it.  However,
I''m
beginning to think that doing aggregations would be a better approach.

Anyway, I was just trying to raise awareness of this limitation and 
figure out whether or not it is a know problem or feature.  BTW, I
don''t
think the system is actually getting bogged down, its just a matter of 
the console output not being able to keep up with the amount of data 
being pumped out of the script.  The test being run continues to run 
just fine, only dtrace aborts.

jim

James Dickens wrote:
>On 1/18/06, Jim Wahlig <James.Wahlig at sun.com> wrote:
>  
>
>>I know I''ve asked about this message in the past:
>>
>>"dtrace: processing aborted: Abort due to systemic
unresponsiveness",
>>
>>but what I don''t know is whether or not it is known that
sending output
>>to the console causes this to happen rather easily and that sending the
>>output to a file prevents this.
>>
>>Is this documented anywhere?  Is this a bug, or just a limitation?
>>
>>Since I have a script that produces a lot of data, do I need to warn
>>people not to run it on the console without redirecting the output to a
>>file, or will people already know not to do that?
>>
>>Thanks for any/all opinions on this.
>>
>>Jim
>>
>>    
>>
>
>wrap it in a shell script or possibly make a perl script that parses
>the output and have it create a summary of the output. maybe use a
>agregation in the dtrace script, if you are bogging the system down
>that much, it may hide the real problem you are looking for in the
>first place.
>
>
>James Dickens
>uadmin.blogspot.com
>
>  
>
>>_______________________________________________
>>dtrace-discuss mailing list
>>dtrace-discuss at opensolaris.org
>>
>>    
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060118/c1214072/attachment.html>