星期四 四月 24, 2008


Hithis is Dtrace Demo, we can use it in our tech talk. I find these information on Hands_on_lab 9520_solaris10dtrace.
Firstly, we can introduce what is Dtrace:
DTrace is a comprehensive dynamic tracing framework for the Solaris Operating Environment. DTrace provides a powerful infrastructure to permit administrators, developers, and service personnel to concisely answer arbitrary questions about the behavior of the operating system and user programs.
There are some background information:
Solaris 10 introduced a new dynamic tracing framework called DTrace.
DTrace allows you to dynamically instrument a live running system to collect any arbitrary information from any arbitrary location in the kernel and applications running in a Solaris 10 system.
DTrace defines trace points called probes which could be turned on and off dynamically.
There are close to 50000 probes defined in a Solaris 10 system.
Secondly, we can give some base command line:
We open a terminal and type command
l
et's list the probes that are available on your system.
# dtrace –l
To find the number of probes in your system, pipe the above command
# dtrace -l | wc –l
list the probes in the sysinfo provider type the following command.
# dtrace -l -P sysinfo | more
To list the probes with the name start type the following
# dtrace -l -n start
After that, we can introduce some base knowledge of Dtrace:
D - Internal ID of the probe listed.
Provider - Name of the Provider. Providers are used to classify the probes. This is also the method of instrumentation.
Module - The name of the Unix module or application library of the probe
Function - The name of the function in which the probe exists.
Name - The name of the probe.
Of course, probes can be listed based on the provider or module or function or name.  You can specify the following options with -l option.
-P for provider
-m for module
-f for function
-n for name
Thirdly, we will introduce Dtrace language and list two demos to tell how to use it:
This is the structure of a D script
probe-description
             /predicate/
             {
                   action statements
             }

             probe-description - probe(s) that you want to instrument
             predicate -  filter to limit the execution of action statements
             action - the statements that collect system state.
Probe-description contains 4 attributes:
      provider - name of the provider ex., pid, syscall, io etc...
      module - name of kernel module or lib name ex. ufs, libc, a.out
      function - name of the function ex. open, close, strcmp
      name - name of the probe. ex. entry, return, start
Let's see the construct of the probe-description
Any one of the attribute can be left out and it will match all possible probes.
Wild card like * and ? can be used in any attribute. Example
     
syscall:::entry - probe describe entry into all syscall
      syscall::open*:entry - probe matches open and open64 syscall
We will write a simple D-script to instrument the system call subsytem to print the name of the system calls that are happening in the system. We will also print the name and process id of the application that is making the system call.
      
Use syscall:::entry as the probe-description
      
Leave the predicate part empty
      
In the action section add printf statement to print the builtin variables probefunc,pid and execname 
Here is how your syscall.d should look like
syscall:::entry
{
      printf("%s(%d) called %s\n", execname, pid, probefunc);
}
Now lets modify the code to only print the system calls made by 'java'
Copy syscall.d to java_syscall.d
Add a predicate to limit for execname == "java"
Modify the printf statement to print the process id (pid)
Here is how java_syscall.d should look like
syscall:::entry
/execname == "java"/
{
          printf("Java(%d) called syscall %s\n", pid, probefunc);
}
Fourly, we will introduce Dtrace Aggregate and give a simple demo:
l  dtrace has a first class data structure called aggregate that helps you in collecting and  processing the data in one step thus dramatically reducing collection cost.
The syntax of aggregate
             @name[key] = aggfunc(args)          
                @
            symbol signifies the aggregate
                name:      optional name of  the aggregate
                key:         optional index of the aggregate
                aggfunc   one of the following
                         count():         count of the event
                         sum(exp):      running total of expression
                         avg(exp):       average of expression
                         min(exp):       min of the given expression
                         max(exp):      max of the expression
                         quantize(exp)a graph of distribution of expression
l  There is a example of aggregate
Use sysinfo:::pswitch as the probe-description
Leave the predicate part empty
In the action section add an aggregate to count the number of signals that are sent using the aggregate statement
@[execname]=count()
Here is how your count_signals.d should look like.
sysinfo:::pswitch
       {
            @[execname]=count();
       }
Run the script that you just wrote
# dtrace -qs count_switch.d  <press Ctrl c after a few seconds>
At last, we will introduce some demos about Dtrace in Java
We will now use DTrace to monitor Class loading, thread creation/destruction & method compilation.
The Classloader probe provide ways to monitor classloading and unloading
The threads probes will allow us to monitor thread creation and deletion
l  First cd to jdk1.6.0/demo/plugin/jfc/Java2D and start the demo app by typing in java -jar Java2Demo.jar
l  Open another window to run the DTrace scripts.
l  We will start with a very simple script to print the creation of new thread. Create a file hotspot_threads.d and type the following into the file.
hotspot$target:::thread-start
{
        printf("New thread with thread id %d started\n", args[2]);
}
The $target variable is the process id passed to the script through the -p option.
The thread-start probe fires when a new thread is created. This script should print when a new thread is created.
run the script as below.
dtrace -qs hotspot_threads.d -p 1234
You can get the Java2Demo to create threads by clicking on one of the demo tabs.
l  Modify the hotspot_threads.d to include thread destruction and also print the name of the thread. You can use the following code for the exercise. This is hotspot_threads_optional.d
hotspot$target:::thread-start
{
        printf("Thread \"%s\" with Thread id %d started\n",copyinstr(arg0,arg1), args[2]);
}
hotspot$target:::thread-stop
{
        printf("Thread \"%s\" with Thread id %d stopped\n",copyinstr(arg0,arg1), args[2]);
}
l  We will now look at a script to monitor classloading. Create a file hotspot_cload.d and type the the following into the file.
hotspot$target:::class-loaded
{
        printf("%s loaded\n", copyinstr(arg0,arg1));
}
Click on a tab in the demo window to cause class loading
l  We can use the DTrace to monitor method compilation events as well. Create a file hotspot_compiles.d and type the following...
hotspot$target:::method-compile-begin
{
       printf("Compilation of %s:%s started\n", copyinstr(arg2,arg3), copyinstr(arg4,arg5));
}
So after we talk the tech in these steps, we can give students a simple introduction of Dtrace. Hope you will like the demo.

评论:

发表一条评论:
  • HTML语法: 禁用