h1. DTrace/Chime Basics Demo (10 Minutes)
h4. Description
This demo introduces DTrace basic concepts and the Chime utility.
h4. OpenSolaris Versions Supported
OpenSolaris 2008.05 or higher.
h4. Points to Hit
* DTrace is very cool
* One tracing tool for kernel and applications
* Although D language is not simple to learn you can still download many free scripts
* You can really know what is happening in the system and that makes you a better admin/developer
* You can hunt bugs and improve performance of your applications
* DTrace providers are available for many of the non-native languages that are available on Solaris: Java, PHP, Ruby, etc.
h4. Demo Prep
* Install Chime: [http://opensolaris.org/os/project/dtrace-chime/install].
* Copy the code listed below into separate files and then just explain the code and run the scripts during presentation.
* Get the [necessary privileges|http://blogs.sun.com/observatory/entry/dtrace_privileges] for your userid by running {{{*}pfexec usermod \-K defaultpriv=basic,dtrace_user,dtrace_proc,dtrace_kernel bleonard{*}}}, substituting your user id, or just *su* or *pfexec bash* in the terminal session where you run the commands below. A similar issue exists for running Chime - you can setup a menu entry for it that uses pfexec to start it.
h4. Gotchas
None known.
h4. Demo
* Run *dtrace \-l \| more* to show all probes. The purpose of doing this is to show that there are a lot of probes available. Explain the listing. Each probe is assigned a number, and is defined by the combination of four things: provider (sort of a subsystem), module (typically a library within the subsystem), function (a method name), and probe name (e.g. entry, return, throw exception, etc.). For a quick overview see [http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_Guide].
* Use Ctrl-C to stop the command. Then run *dtrace \-l \| wc \-l* to get the total count of probes in the system.
* Which system calls are being executed? This script shows all system calls executed while the script is running. Display file syscall.d:
{noformat}
syscall:::entry
{
printf("%s(%d) called %s\n", execname, pid, probefunc);
}
{noformat}
Explain the basics of the D language. The first line is a pattern for specifying the probes to match. If someone asks: "Uhm, how in the world are you supposed to know that 'syscall' is the name of a provider?" tell them to hold that thought. :-) The printf is easy - standard formatting from C, along with some pre-defined D variables. In this case, probefunc is the 3rd component of the probe. So for example, if we only wanted to see entries into the {{read}} function, we could modify the script as follows:
{noformat}
syscall::read:entry
{
printf("%s(%d) called %s\n", execname, pid, probefunc);
}
{noformat}
* Run *dtrace \-qs syscall.d* (the *q* option is quite mode, the *s* option is source file). You will see system calls appearing as you use the OS.
* Press Ctrl-C to stop dtrace.
h5. Predicates
Point out that the dtrace command itself shows up in the output. How could we prevent that?
* Edit syscall.d (preferably with vi, to establish additional "geek cred" :-) ) and add a predicate:
{noformat}
syscall:::entry
/ pid != $pid /
{
printf("%s(%d) called %s\n", execname, pid, probefunc);
}
{noformat}
Explain that a predicate controls the behavior of dtrace by applying a condition. In this case, if the PID of the program that is calling the system is dtrace's PID, then we don't want the output.
* Run *dtrace \-qs syscall.d*. You will see system calls appearing as you use the OS, only this time, without any entries for dtrace.
* Press Ctrl-C to stop dtrace.
h5. Aggregates
How do we roll up results over time? In other words, if instead of seeing all the methods we just want to know how many system calls are being made by all processes, how would that be done?
* Display file syscalls_overtime.d:
{noformat}
syscall:::entry
/ pid != $pid /
{
@a[execname] = count();
}
{noformat}
* Explain that @ is used to indicate an aggregate, in this case, one that is indexed by process name. The count() method is one of the aggregation methods provided by DTrace.
* Run *dtrace \-qs syscalls_overtime.d*. No output is displayed. Explain that since the script is only doing aggregation, the default behavior is for dtrace to display the results of that aggregate when dtrace exits.
* Press Ctrl-C to see the output.
h5. Chime
* "You might be wondering - uhm, is there a GUI available?" :-) The answer is: Yes\!
* Start Chime.
* Run the *System Calls* trace:
!Screenshot-Chime.png!
* A second window will open:
!Screenshot-System Calls.png!
This is essentially the same output that was displayed by syscalls_overtime.d, but with several important advantages. The first advantage is that the data is refreshed once per second to show system calls per second. The other advantage is the historical trend graph.
* Right-click anywhere in the System Calls window and choose "Look at DTrace Program":
!Screenshot-System Calls-Program.png!
Using Chime is a nice way to help learn the D language. Close the DTrace program window.
* Right-click one the more active System Call executables and view it by function:
!Screenshot-VirtualBox System Calls by Function.png!
So another nice feature of Chime is the ability to drill down.
* Close the System Calls by Function and System Calls windows. Point out that Chime includes a variety of different DTrace scripts, each of which has an XML file used by Chime to define the graphical display. There is a wizard available for creating that XML file.
* Chime can also display the available probes. This is where it can be a very helpful learning tool, and provides an answer to the question of "Uhm, how in the world are you supposed to know that 'syscall' is the name of a provider?" Select *File > List Probes* and pull down the Provider list to show the entry for *syscall*:
!Screenshot-ListProbes.png!
* Select *entry* from the Name list and then click the *List Probes* button:
!Screenshot-ListProbes2.png!
* Close Chime.
* Mention that in addition to the D scripts with Chime, there are samples in {{/usr/demo/dtrace}} that are described in the [Solaris Dynamic Tracing Guide|http://docs.sun.com/app/docs/doc/817-6223]. There is also the very cool [DTrace Toolkit|http://www.opensolaris.org/os/community/dtrace/dtracetoolkit/] which has lots of scripts.
* Point out that DTrace providers are available for many of the non-native languages that are available on Solaris: Java, PHP, Ruby, etc. So you can see what is going on inside applications written in those languages.
h5. Other Fun Chime Scripts
* DTraceToolkit > cpudists
* DTraceToolkit > wpm
h4. Demo Cleanup
* Remove the predicate from syscalls.d
h4. Description
This demo introduces DTrace basic concepts and the Chime utility.
h4. OpenSolaris Versions Supported
OpenSolaris 2008.05 or higher.
h4. Points to Hit
* DTrace is very cool
* One tracing tool for kernel and applications
* Although D language is not simple to learn you can still download many free scripts
* You can really know what is happening in the system and that makes you a better admin/developer
* You can hunt bugs and improve performance of your applications
* DTrace providers are available for many of the non-native languages that are available on Solaris: Java, PHP, Ruby, etc.
h4. Demo Prep
* Install Chime: [http://opensolaris.org/os/project/dtrace-chime/install].
* Copy the code listed below into separate files and then just explain the code and run the scripts during presentation.
* Get the [necessary privileges|http://blogs.sun.com/observatory/entry/dtrace_privileges] for your userid by running {{{*}pfexec usermod \-K defaultpriv=basic,dtrace_user,dtrace_proc,dtrace_kernel bleonard{*}}}, substituting your user id, or just *su* or *pfexec bash* in the terminal session where you run the commands below. A similar issue exists for running Chime - you can setup a menu entry for it that uses pfexec to start it.
h4. Gotchas
None known.
h4. Demo
* Run *dtrace \-l \| more* to show all probes. The purpose of doing this is to show that there are a lot of probes available. Explain the listing. Each probe is assigned a number, and is defined by the combination of four things: provider (sort of a subsystem), module (typically a library within the subsystem), function (a method name), and probe name (e.g. entry, return, throw exception, etc.). For a quick overview see [http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_Guide].
* Use Ctrl-C to stop the command. Then run *dtrace \-l \| wc \-l* to get the total count of probes in the system.
* Which system calls are being executed? This script shows all system calls executed while the script is running. Display file syscall.d:
{noformat}
syscall:::entry
{
printf("%s(%d) called %s\n", execname, pid, probefunc);
}
{noformat}
Explain the basics of the D language. The first line is a pattern for specifying the probes to match. If someone asks: "Uhm, how in the world are you supposed to know that 'syscall' is the name of a provider?" tell them to hold that thought. :-) The printf is easy - standard formatting from C, along with some pre-defined D variables. In this case, probefunc is the 3rd component of the probe. So for example, if we only wanted to see entries into the {{read}} function, we could modify the script as follows:
{noformat}
syscall::read:entry
{
printf("%s(%d) called %s\n", execname, pid, probefunc);
}
{noformat}
* Run *dtrace \-qs syscall.d* (the *q* option is quite mode, the *s* option is source file). You will see system calls appearing as you use the OS.
* Press Ctrl-C to stop dtrace.
h5. Predicates
Point out that the dtrace command itself shows up in the output. How could we prevent that?
* Edit syscall.d (preferably with vi, to establish additional "geek cred" :-) ) and add a predicate:
{noformat}
syscall:::entry
/ pid != $pid /
{
printf("%s(%d) called %s\n", execname, pid, probefunc);
}
{noformat}
Explain that a predicate controls the behavior of dtrace by applying a condition. In this case, if the PID of the program that is calling the system is dtrace's PID, then we don't want the output.
* Run *dtrace \-qs syscall.d*. You will see system calls appearing as you use the OS, only this time, without any entries for dtrace.
* Press Ctrl-C to stop dtrace.
h5. Aggregates
How do we roll up results over time? In other words, if instead of seeing all the methods we just want to know how many system calls are being made by all processes, how would that be done?
* Display file syscalls_overtime.d:
{noformat}
syscall:::entry
/ pid != $pid /
{
@a[execname] = count();
}
{noformat}
* Explain that @ is used to indicate an aggregate, in this case, one that is indexed by process name. The count() method is one of the aggregation methods provided by DTrace.
* Run *dtrace \-qs syscalls_overtime.d*. No output is displayed. Explain that since the script is only doing aggregation, the default behavior is for dtrace to display the results of that aggregate when dtrace exits.
* Press Ctrl-C to see the output.
h5. Chime
* "You might be wondering - uhm, is there a GUI available?" :-) The answer is: Yes\!
* Start Chime.
* Run the *System Calls* trace:
!Screenshot-Chime.png!
* A second window will open:
!Screenshot-System Calls.png!
This is essentially the same output that was displayed by syscalls_overtime.d, but with several important advantages. The first advantage is that the data is refreshed once per second to show system calls per second. The other advantage is the historical trend graph.
* Right-click anywhere in the System Calls window and choose "Look at DTrace Program":
!Screenshot-System Calls-Program.png!
Using Chime is a nice way to help learn the D language. Close the DTrace program window.
* Right-click one the more active System Call executables and view it by function:
!Screenshot-VirtualBox System Calls by Function.png!
So another nice feature of Chime is the ability to drill down.
* Close the System Calls by Function and System Calls windows. Point out that Chime includes a variety of different DTrace scripts, each of which has an XML file used by Chime to define the graphical display. There is a wizard available for creating that XML file.
* Chime can also display the available probes. This is where it can be a very helpful learning tool, and provides an answer to the question of "Uhm, how in the world are you supposed to know that 'syscall' is the name of a provider?" Select *File > List Probes* and pull down the Provider list to show the entry for *syscall*:
!Screenshot-ListProbes.png!
* Select *entry* from the Name list and then click the *List Probes* button:
!Screenshot-ListProbes2.png!
* Close Chime.
* Mention that in addition to the D scripts with Chime, there are samples in {{/usr/demo/dtrace}} that are described in the [Solaris Dynamic Tracing Guide|http://docs.sun.com/app/docs/doc/817-6223]. There is also the very cool [DTrace Toolkit|http://www.opensolaris.org/os/community/dtrace/dtracetoolkit/] which has lots of scripts.
* Point out that DTrace providers are available for many of the non-native languages that are available on Solaris: Java, PHP, Ruby, etc. So you can see what is going on inside applications written in those languages.
h5. Other Fun Chime Scripts
* DTraceToolkit > cpudists
* DTraceToolkit > wpm
h4. Demo Cleanup
* Remove the predicate from syscalls.d