Solaris Dynamic Tracing Guide

profile-n probes

A profile-n probe fires every fixed interval on every CPU at high interrupt level. The probe's firing interval is denoted by the value of n: the interrupt source will fire n times per second. n may also have an optional time suffix, in which case n is interpreted to be in the units denoted by the suffix. Valid suffixes and the units they denote are listed in Table 19–1.

Table 19–1 Valid time suffixes


Time Units 

nsec or ns


usec or us


msec or ms


sec or s


min or m


hour or h


day or d



hertz (frequency per second) 

The following example creates a probe to fire at 97 hertz to sample the currently running process:

#pragma D option quiet

/pid != 0/
	@proc[pid, execname] = count();

	printf("%-8s %-40s %s\n", "PID", "CMD", "COUNT");
	printa("%-8d %-40s %@d\n", @proc);

Running the above example for a brief period of time results in output similar to the following example:

# dtrace -s ./prof.d
PID      CMD                                      COUNT
223887   sh                                       1
100360   httpd                                    1
100409   mibiisa                                  1
223887   uname                                    1
218848   sh                                       2
218984   adeptedit                                2
100224   nscd                                     3
3        fsflush                                  4
2        pageout                                  6
100372   java                                     7
115279   xterm                                    7
100460   Xsun                                     7
100475   perfbar                                  9
223888   prstat                                   15

You can also use the profile-n provider to sample information about the running process. The following example D script uses a 1,001 hertz profile probe to sample the current priority of a specified process:

/pid == $1/
	@proc[execname] = lquantize(curlwpsinfo->pr_pri, 0, 100, 10);

To see this example script in action, type the following commands in one window:

$ echo $$
$ while true ; do let i=0 ; done

In another window, run the D script for a brief period of time, replacing 12345 with the PID that your echo command returned:

# dtrace -s ./profpri.d 12345
 dtrace: script './profpri.d' matched 1 probe
           value  ------------- Distribution ------------- count    
             < 0 |                                         0        
               0 |@@@@@@@@@@@@@@@@@@@@@                    7443     
              10 |@@@@@@                                   2235     
              20 |@@@@                                     1679     
              30 |@@@                                      1119     
              40 |@                                        560      
              50 |@                                        554      
              60 |                                         0 

This output shows the bias of the timesharing scheduling class. Because the shell process is spinning on the CPU, its priority is constantly being lowered by the system. If the shell process were running less frequently, its priority would be higher. To see this result, type Control-C in the spinning shell and run the script again:

# dtrace -s ./profpri.d 494621
 dtrace: script './profpri.d' matched 1 probe

Now in the shell, type a few characters. When you terminate the DTrace script, output like the following example will appear:

           value  ------------- Distribution ------------- count    
              40 |                                         0        
              50 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 14       
              60 |                                         0

Because the shell process was sleeping awaiting user input instead of spinning on the CPU, when it did run it was run at a much higher priority.