dtrace discuss - Jun 2006 - [Fwd: Persistent "Abort due to systemic unresponsiveness"]

Just adding a few more details to the previous mail so that I can avoid 
some trouble for you folks.

1. I have done a /execname != "dtrace"/ to avoid dtrace itself causing
more syscalls to be fired.
2. I have also supressed the printing on the terminal which makes dtrace 
slower.

And what happens is this:
dtrace -qn ''syscall::read:entry /execname != "dtrace"/ {
@[execname] =
count();}''
dtrace: processing aborted: Abort due to systemic unresponsiveness

Cheers,
Ananth
-------------- next part --------------
An embedded message was scrubbed...
From: Ananth Shrinivas <Ananth.Shrinivas at Sun.COM>
Subject: [dtrace-discuss] Persistent "Abort due to systemic
unresponsiveness"
Date: Tue, 06 Jun 2006 19:44:47 +0530
Size: 6992
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060606/ce68eaa4/attachment.nws>

On Tue, Jun 06, 2006 at 08:14:57PM +0530, Ananth Shrinivas
wrote:
> Just adding a few more details to the previous mail so that I can avoid 
> some trouble for you folks.
> 
> 1. I have done a /execname != "dtrace"/ to avoid dtrace itself
causing
> more syscalls to be fired.
> 2. I have also supressed the printing on the terminal which makes dtrace 
> slower.
> 
> And what happens is this:
> dtrace -qn ''syscall::read:entry /execname != "dtrace"/ {
@[execname] =
> count();}''
> dtrace: processing aborted: Abort due to systemic unresponsiveness
> 
> Hi DTracers,
> 
> I happen to hit the DTrace Systemic Unreponsiveness issue rather too 
> frequently on my x86 box running Nevada (b35). I undestand that this 
> happens when "one of the deadman timers intervenes and kills your
dtrace
> process, when it decides that dtrace has put too much load on the
system".
> 
> The problem is that, I encounter this even when running (what i beleive 
> are) relatively lightweight probes. Probes like
''syscall::write:entry''
> abort immediately after starting. Same happens with a lot of other 
> probes. The machine I execute the script on is a Dual CPU AMD64 box 
> running at ~2000Mhz with 2GB RAM (Xorg is running but its not Sooo bad, 
> is it ?). I am able to run the same probes succesfully without any 
> problems on a low end UltraSparc boxes running nevada or s10.
Are you running any kind of power management?  This could be a
gethrtime()-jumping problem.

Cheers,
- jonathan
> Of course I am able to workaround this issue by dtrace -w, And there is 
> absolutely no sign of the smallest performance degradation on the system 
> when I do so. But in that case why is the deadman timer being so paranoid ?
> 
> It would be great if someone could shed light on these following queries
> 1. First of all does it *sound* sane that this problem happens even for 
> just read/write/open syscall probes on a relatively "fast"
machine ?
> 2. Is the deadman timer causing Dtrace to fail same as the one in the 
> Cyclic Subsystem ? If not where in the source should i look to 
> understand more about these timers and their trigger conditions ?
> 
> Cheers,
> Ananth
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Jonathan Adams, Solaris Kernel Development