Chris's Wiki :: blog/solaris/DTraceWhyNot Commentshttps://utcc.utoronto.ca/~cks/space/blog/solaris/DTraceWhyNot?atomcommentsDWiki2012-12-29T00:02:12ZRecent comments in Chris's Wiki :: blog/solaris/DTraceWhyNot.From 209.118.197.222 on /blog/solaris/DTraceWhyNottag:CSpace:blog/solaris/DTraceWhyNot:deeea4b9abcea0cff05f17a4d02a3883c9410c81From 209.118.197.222<div class="wikitext"><p>Agree with Brendan. DTrace could use a higher level wrapper language.
DTrace could also use a graphical interface. Neither of these endeavors is easy or clear.
A analogous example, though probably out of most kernel people's experience, is active session history (ASH) in Oracle databases. ASH collects session state from all active (non-idle) Oracle database sessions. ASH collects time, current SQL statement, state (on CPU, waiting, if waiting what is it waiting for , about 1000 different possibilities) and another almost 100 different dimensions. The data is extremely powerful and it's kept by default for a week thus enabling post analysis of problems that happened up to a week ago. Almost no average DBA uses the data directly. The data is direct accessible via SQL queries but the barrier to entry is a too high for the average DBA. On the other hand when the data is externalized graphically as in "Top Activity Page" in Oracle Enterprise manager see <a href="http://bit.ly/YVgdb2">http://bit.ly/YVgdb2</a> (or lab128, or ashviewer, or ashmon, or DB Optimizer), then the average DBA can use the data. The graphic interface gives an immediate view of database load, type of load, bottlenecks and allows the user to pick time ranges and drill down into sessions and bottlenecks.
The same would be true of DTrace - provide an interface that has a lower barrier of entry and more people would hop on.</p>
</div>2012-12-29T00:02:12ZBy Chris Siebenmann on /blog/solaris/DTraceWhyNottag:CSpace:blog/solaris/DTraceWhyNot:0a4d916efcf61a4872b2399d448f376fb8b8e4faChris Siebenmann<div class="wikitext"><p>As a brief (and belated) note: I plan to write something in response to
Brendan Gregg's comments, but they deserve something more considered
than a quick off the cuff reaction so it's going to take some time.</p>
<p>(My reactions will probably appear slowly across several entries,
when they eventually get written.)</p>
</div>2012-04-14T06:12:24ZFrom 38.104.194.102 on /blog/solaris/DTraceWhyNottag:CSpace:blog/solaris/DTraceWhyNot:ba330b9ed641188a075951b40156eb1a7e606c68From 38.104.194.102<div class="wikitext"><p>Thanks for describing this issue Chris. I hope to hear from others as well, so we can collectively figure out how to improve adoption.</p>
<p>The comment about a lack of documented trace points sounds a bit like earlier versions of DTrace. We do have more now, and can add more. However, there is a point where adding probes makes no sense: the extra effort to learn new probes and how they map to the implementation outweighs learning just the implementation. In those cases, it's critical to have either source code access - as you said was ideal - or a permissive T&Cs that allow reverse engineering. Some of my last big wins from DTrace were only possible because I could check the source code to what I was tracing (this is on illumos/SmartOS).</p>
<p>I was a little confused at first about the language and documentation issues. Usually language discussions (eg, Python vs Ruby) are intended to pick one over another, but in this case there is no other option to choose from. So if these problems are raising the barrier to entry for some people, and they aren't entering, then what are they doing? Leaving system problems unsolved?</p>
<p>It's been mentioned a few times, but I suspect it would be possible to create a higher level language ("D++") that speaks to libdtrace. An advantage of D being low level is that the user is conscious of how the system is actually getting traced, in the same way that C is low level. But C isn't for everyone.</p>
<p>As for sysadmin documentation - I'd recommend the DTraceToolkit and Solaris Performance and Tools (Prentice Hall), which are both aimed at sysadmins.</p>
<p>--
Brendan Gregg
<a href="http://dtrace.org/blogs/brendan">http://dtrace.org/blogs/brendan</a></p>
</div>2012-04-11T20:56:18ZFrom 78.148.183.54 on /blog/solaris/DTraceWhyNottag:CSpace:blog/solaris/DTraceWhyNot:aa36ddbb462656c3c98f3a6bb1401aec4cd322feFrom 78.148.183.54<div class="wikitext"><p>I've always assumed that the main advantage of DTrace is that your support provider (namely Sun, as-was) could use it to diagnose and resolve your obscure system issue quickly and easily, by providing the magic DTrace-fu you needed. Any user access to it was mostly a bonus, if you were smart enough to figure out how to take advantage of it.</p>
<p>Whether this still carries much weight when you're relying on Oracle Support, I remain sceptical.</p>
</div>2012-04-08T09:22:24ZFrom 70.31.29.25 on /blog/solaris/DTraceWhyNottag:CSpace:blog/solaris/DTraceWhyNot:ff438efc26c055857c2c3b5482f7f2abe297e266From 70.31.29.25<div class="wikitext"><p>I wonder how many Mac OS X developers use Instruments to debug things on Apple systems:</p>
<p><a href="http://en.wikipedia.org/wiki/Instruments_(application">http://en.wikipedia.org/wiki/Instruments_(application</a>)</p>
</div>2012-04-06T15:26:27Z