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 about 1 microsecond per probe
(rough approximation).
In general, the cost of using DTrace in terms of probe effect
is directly proprotional to two things;
- the number of probes you enable.
- the activity of the code path of the enabled probe(s).
In other words, if you instrument the fork system call,
and the system is not executing forks, you won't feel a thing.
If, on the other hand, the system is going 1000 forks per second,
you'll feel it.
The specopen.d script enables all the fbt probes. Even with
the predicate ( / self->spec / ), the probe still has to fire before
the predicate gets evaluated.
HTH,
/jim
tester wrote:
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 without the script is moderately loaded (usr+sys
~30-40).
Also, I have to bump up the number of speculative buffers to 10 to avoid some
of the warnings. What is a good rule to set the number of speculative buffers?
In this case is it based on the number of fork calls that could be
simultaneously traced?
Thanks
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
