Photo copyright www.elberling.dk
I. hate. slow. code.
We all hate slow code. Bunch of princesses is what we've become. During the American Civil War, they had to deliver their text messages by horseback! It took weeks! And half the time, they got blown off their horse by a cannonball to the neck!
Today? Today we have to have our stuff back in milliseconds, or we start tweeting about it. So, if you're developing or deploying applications, how do you keep them performing at the speed to which we have become accustomed? DTrace, of course.
"But I'm a Linux guy," you say. "I don't DO Oracle Solaris."
That's fine. The folks at Oracle Solaris are not only wicked smart, they are generous. Now you can use DTrace on Oracle Linux. Let me point out, by the way, that DTrace is just as useful for sysadmins as it is for developers. In this video, taken a couple of years ago, Brendan Gregg explains how sysadmins can make their deployed applications run faster even after the developers who wrote them pushed back the last bits of their code:
Video Interview: How to Improve the Performance of Deployed Applications Using DTrace
Brendan Gregg describes the best ways for sysadmins to tune deployed applications to get more performance out of them in their particular computing environment.
Bonus: More info about Brendan Gregg plus links to his personal and professional blogs.
If you'd like to try DTrace on Oracle Linux, here are some resources to get you started.
What DTrace Probes Are Available on Oracle Linux?
If you are running Oracle Linux 6 with the DTrace-enabled Unbreakable Enterprise Kernel Release 2 (2.6.39), you can run this command to list all the DTrace probes available on your system:
dtrace -lIf you are not running that version of Oracle Linux, you can download it from the ol6_x86_64_Dtrace_latest channel on the Unbreakable Linux Network (ULN). For more info about installing and configuring DTrace, see the DTrace chapter in the Oracle Linux Administrator's Solutions Guide for Release 6.
For each probe listed by dtrace -l, the output includes a name, the portion of the program where it resides, and the Oracle Linux kernel module that does the probing. Once you have that, go to Chapter 11 of the DTrace Guide to find out what each probe does.
Article: How to Get Started Using DTrace on Oracle Linux
DTrace is a powerful tool, and it can do some amazing things. But it's not that difficult to get started doing simple things. You can build up from there. In this article, Richard Friedman gives you a high-level overview of DTrace and its major components:providers, modules, functions, and probes. He explains how you can use either one-liner commands on the command line, or write more complex instructions in scripts, using the D language. He provides simple examples for each. It's a great way to get your feet wet.
Article: How to Get Started Using DTrace on Oracle Linux
Bonus: Brendan Gregg's one liners for DTrace (some of the existing DTrace one-liners will require modification to work on Oracle Linux).
The DTrace Book
You can get all the info you need about DTrace through the Dynamic Tracing in Oracle Solaris, Mac OS X, and FreeBSD, by Brendan Gregg and Jim Mauro. Of course, you can also buy your own paper or electronic copy through any of the major retailers. (We're working on getting a good discount for the book, but you'll have to subscribe to the OTN Systems Community Newsletter to find out about it.)
Bonus:How the DTrace book got done, by Deirdre Straughan
DTrace Forums
Lots of developers and sysadmins are using Dtrace and posting their questions and tips on the DTrace Forum. Here's an example of one conversation:
Q: Unexpected output of dtrace scriptm1436wrote a dtrace script to monitor the bytes returned by the read() system call to the user programme, but was getting strange results. He includes the dtrace script and the strange output. A:kvhresponds, explaining that the problem m1436 encountered is the result of a common misconception about copyin(). "It is intended to be used to copy content of userspace memory into a scratch buffer so that it can be accessed directly from within kernel space (where the DTrace core executes). That said, it is often interpreted as somehow being equivalent to malloc() whereas in reality it actually works like alloca() instead. So, what you are seeing is basically the artifact of the scratch buffer being overwritten with other data. ... in order for this to work, you should do things a bit differently.
The DTrace forum always has great discussions. Let me know if you find any that are worthy of highlighting. And good luck!
- Rick
Follow me on:
Blog | Facebook | Twitter | YouTube | The Great Peruvian Novel