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. Table 11-29 lists the valid suffixes and the units denoted by the suffix.
Table 11-29 Valid Time Suffixes for the profile Probe
| Suffix | Time Units |
|---|---|
|
|
nanoseconds |
|
|
microseconds |
|
|
milliseconds |
|
|
seconds |
|
|
minutes |
|
|
hours |
|
|
days |
|
|
hertz (frequency per second) |
Example 11-10 Using a Profile Probe to Sample a Process
The following example creates a probe to fire at 97 hertz to sample the currently running process:
#pragma D option quiet
profile-97
/pid != 0/
{
@proc[pid, execname] = count();
}
END
{
printf("%-8s %-40s %s\n", "PID", "CMD", "COUNT");
printa("%-8d %-40s %@d\n", @proc);
}
Running the preceding example for a brief period of time results in output similar to the following example:
# dtrace -s ./prof.d
^C
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:
profile-1001
/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 $$
494621
$ while true ; do let i=0 ; done
In another window, run the D script for a brief period of time:
# dtrace -s ./profpri.d 494621
dtrace: script './profpri.d' matched 1 probe
^C
ksh
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 time-sharing 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
Type a few characters in the shell. When you terminate the DTrace script, output like the following example will appear:
ksh
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.