dtrace discuss - Sep 2006 - DTrace tools for reduced memory & increased accuracy

Dtrace Gurus,

Any ideas on Dtrace tools that could be used to meet/exceed some of
the current sysadmin tools, such as top, netstat, iostat, kstat, ...

Is it more efficient (lower memory & cpu usage) to utiize Dtrace tools
or compiles applications such as top, netstat, iostat, kstat?

Cheers,
Joel


Joel.Buckley at Sun.COM
303-272-5556, x75556
"Luck is a Planned Event."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Joel.Buckley.vcf
Type: text/x-vcard
Size: 331 bytes
Desc: Card for Joel Buckley <Joel.Buckley at Sun.COM>
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060920/1e6b8ca0/attachment.vcf>

Joel,

I realize you didn''t ask for a sermon, but since I don''t know
your
goals, allow me to give you a small one.  :-)

*stat commands and DTrace compliment each other, and are not good 
substitutes.  Even though you could get any info you wanted from kernel 
data structures and using the profile provider to give you a timer, it 
would be like carving a large screwdriver into some kind of hammer in 
order to have something to strike nails.  It was much better for 
screwing in screws than it would ever be at hammering nails.  OK, enough 
with the obvious simile.  *stat commands were designed to gather broad 
kernel data on a timer, and DTrace was designed to gather event related 
kernel when those events occur.

As an example, "lockstat" is one of the commands that _was_ replaced 
with a DTrace script.  But "lockstat" is event driven.

Also, even though you can do it, I don''t believe gathering arbitrary 
kernel data on a timed event in DTrace would be any more efficient than 
the existing tools.  Any other opinions on that?

IMHO,
Chip

Joel Buckley wrote:
> Dtrace Gurus,
>
> Any ideas on Dtrace tools that could be used to meet/exceed some of
> the current sysadmin tools, such as top, netstat, iostat, kstat, ...
>
> Is it more efficient (lower memory & cpu usage) to utiize Dtrace tools
> or compiles applications such as top, netstat, iostat, kstat?
>
> Cheers,
> Joel
>
>
> Joel.Buckley at Sun.COM
> 303-272-5556, x75556
> "Luck is a Planned Event."
>   
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Hey Chip,
> I realize you didn''t ask for a sermon, but since I don''t
know your
> goals, allow me to give you a small one.  :-)
You''re so polite -- normally I just plunge into the sermon. ;)
> *stat commands and DTrace compliment each other, and are not good 
> substitutes.  Even though you could get any info you wanted from kernel 
> data structures and using the profile provider to give you a timer, it 
> would be like carving a large screwdriver into some kind of hammer in 
> order to have something to strike nails.  It was much better for 
> screwing in screws than it would ever be at hammering nails.  OK, enough 
> with the obvious simile.  *stat commands were designed to gather broad 
> kernel data on a timer, and DTrace was designed to gather event related 
> kernel when those events occur.
Yes -- amen.  The distinction here should be based on enabled probe effect:
the statistics have essentially zero enabled probe effect, allowing one
to leave them on all the time.  This data is essential when trying
to formulate that first question to ask with DTrace -- which is why we
have tried to develop providers that provide probes that correspond to
those statistics.
> As an example, "lockstat" is one of the commands that _was_
replaced
> with a DTrace script.  But "lockstat" is event driven.
And lockstat was no simple bean counter -- it was implemented in terms
of dynamic instrumentation, and was actually quite exciting in its
implementation.  (An implementation that lives on today as the lockstat
provider.)
> Also, even though you can do it, I don''t believe gathering
arbitrary
> kernel data on a timed event in DTrace would be any more efficient than 
> the existing tools.  Any other opinions on that?
Agreed -- and I think the work needs to be on easing the transition from
examining statistics to trying to understand the source of those statistics
with DTrace.  We tried to do this with the sysinfo, vminfo, fpuinfo and
mib providers -- but there''s more work to do, especially in the
networking
domain.

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

Joel Buckley wrote:
> Any ideas on Dtrace tools that could be used to meet/exceed some of
> the current sysadmin tools, such as top, netstat, iostat, kstat, ...
For a start, don''t use top.   Use prstat.

- Jeremy