Jim,
Thanks. You are right, I was using the specopen.d, but looking for fork errors
instead of open. I did not know that probe has to fire before predicate gets
evaluated. It now makes sense for 40% increase in load during dtracing. I
would like to see the code path during a fork failure (and
Ah, OK - I think I get it.
tester wrote:
counting system call process during this interval: Dtrace came on top
ioctl dtrace 10609
Got it. DTrace executed 10,609 system calls during your sampling period,
more than any other process. I often filter dtrace out in a predicate;
/ execname !=
I'm sorry, but I am unable to parse this.
What is the question here?
Thanks,
/jim
tester wrote:
counting system call process during this interval: Dtrace came on top
ioctl dtrace 10609
I am sure if that is from the speculative dtrace script or the script used to
count the system calls.
Th
counting system call process during this interval: Dtrace came on top
ioctl dtrace 10609
I am sure if that is from the speculative dtrace script or the script used to
count the system calls.
Thanks
--
This message posted from opensolaris.org
___
dtra
Which example are you using, specopen.d, /*the script
that instruments every fbt probe*/?
Please post or be more precise about which script you're using.
If you're using specopen.d, than you're enabling on the
order of 30,000 probes. That's going to add up, even at
the very reasonable cost of ab
Hi,
On a T5220, when using the speculative tracing there is a signifcant increase
on system load. I am using the examples from
http://wikis.sun.com/display/DTrace/Speculative+Tracing
The system call traced is fork instead of open64. Can that script cause such a
load? The system itself withou
