Slashdot Mirror
Solaris' Dtrace in Detail
paulkoan writes "The Register has a further details about the new Dtrace systems utility bundled with Solaris 10, along with pictures of the authors, and user testimonials. It also highlights Suns vague assurances that this (if it lives up to the hype) amazing utility may or may not end up in the public domain."
It's a mechanism for adding trace calls to pretty-nearly-arbitrary locations.
davecb@spamcop.net
An excellent article at sys admin mag.
No, linux does not already do this.
Solaris users could not care less whether Sun ports it to linux or not.
Sun are *not* evil because they don't immediately give away the source to a product which has taken them years and $$$s to develop and which gives them an edge in a competetive market.
Some people just prefer Solaris. If you prefer linux, that's fine.
It is much, much more than that. The problem I find with a "well-sorted collection of individual tools" in this case is the complexity/difficulty/impossibility to do what dtrace can do. Check out this usenet posting for some examples.
I've been using it for a little while, it's a very interesting tool.
They seem to have a lot of praise from users, not just market speak. And technical users yet.
I'd be very, VERY surprised if Sun allows Dtrace into the open source world, at least not for a while. If Dtrace really is the supertool it seems to be, and is actually and massively UNIQUE, it represents a reason peole will move to Solaris and buy Sun's hardware to do it. Maybe the closest thing to a Unix killer app that has existed for a while.
Now eventually (as in five years down the road) it will probably pay for Sun to open it up. If I were them, I'd milk it for all its worth on the "get people to move to Sun boxes" mantra, while the rest of the world trys (and probably fails) to duplicate the tool. Then, when Sun has gotten all the converts they are likely to, start making the tool even BETTER by opening it up and letting the world go to town on it. (GPL or something similar so Sun can incorporate back in the goodies.)
Of course, that's just an off the cuff theory by someone who doesn't know.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Dynamic Instrumentation of Production Systems - this paper was presented at Usenix, and describes how Dtrace is actually implemented.
Dtrace user guide.
A collection of Dtrace scripts
I don't think Sun's open sourcing the thing will help Linux users much anyway, the kernel design is probably very different, with more evolved semantics. Which means Linux developers will hae to do the work themselves if they want their admins to have these facilites.
Note that this is finally a tool to resolve finger-pointing *it's your app that's slow - no it's the kernel etc* . I guess IBM will find it advantageous to create a similar Linux tool for their systems, as they bill Linux as an application serving environment. So we should see it soon on our own boxen.
The sad thing is this proves once again that closed source companies retain an edge at innovating.
This is not a signature.
Dtrace Usenix Paper
More examples in answerbook from the BigAdmin Dtrace page
The mechanism (dynamic instrumentation) is similar. What makes DTrace unique over and above k/dprobes is the incredible power of the 'D' script language. It features things such as speculations (look at the docs on sun.com) that are absolutely vital in many situations for diagnosing problems - too much data is often as bad as too little data, and DTrace lets you easily get exactly the data you want, and only the data you want.
You can find a small section comparing kprobes with DTrace in the DTrace USENIX paper; it also mentions some other differences (kprobes can easily crash your production system; that won't happen with DTrace).
actually that's not true. Kerninst does exactly that.
Kerninst is a framework for dynamically splicing code into a running kernel, almost anywhere, anytime. Code can be removed and changed at will. Kerninst works on standard (unmodified) Solaris and Linux kernels, *no* kernel re-compilation is necessary.
I'll have to start using that in my conversations about lusers. "I wouldn't call him stupid; let's just say he doesn't have a good relationship with his brain..." :)
Sinepaw.org: Grape Winos
I wrote OProfile, and I currently use DTrace daily, and I can assure you that you are wrong when you claim they do the same thing.
OProfile is useful for measuring system-wide resource consumers (for example, you can see what pieces of code are causing cache misses in the kernel when your apache process is in the kernel etc, or which user processes take up the most CPU time).
DTrace can also do something similar (though it needs a little more work yet). But DTrace does a LOT more than this. Imagine a system-wide (kernel, binaries, libraries) 'strace', where you can trivially choose what to print out, and what parts to strace, and under what circumstances. DTrace does even more than that.
OProfile can't tell you exactly why your system call is returning EINVAL. OProfile can't tell you why your application is causing cross-calls. OProfile can't tell you what processes are writing to what files, in real time. OProfile can't debug race conditions.
OProfile is a profiler: it does its job and nothing more. DTrace is, essentially, an instrumentation suite; one of its abilities is to function as a simple profiler.
You won't really get a notion of why DTrace is so useful until you try it.
-- Remove the trailing '\0' to email me.
are you kidding? DTrace lets you do this not just per process, but per instruction, across CPUs. Comparing DTrace to perfmon is like comparing a Ferrari to a tricycle.