profile-n-Prüfpunkte

Ein profile-n-Prüfpunkt wird in einem festgelegten, regelmäßigen Abstand auf jeder CPU mit einer hohen Interrupt-Ebene ausgelöst. Das Auslösungsintervall des Prüfpunkts wird durch den Wert von n bestimmt: Die Interrupt-Quelle wird n-mal pro Sekunde ausgelöst. Sie können n auch ein optionales Zeitsuffix anfügen. In diesem Fall wird n in der mit dem Suffix angegebenen Zeiteinheit interpretiert. Tabelle 19–1 zeigt die gültigen Suffixe und die von ihnen bezeichneten Einheiten.

Das nächste Beispiel erzeugt einen Prüfpunkt, der den aktuell laufenden Prozess prüft und mit einer Frequenz von 97 Hertz ausgelöst wird:

#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);
}

Wenn der obige Code kurz ausgeführt wird, erhalten wir eine ähnliche Ausgabe wie in folgendem Beispiel:

# 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

Mit dem profile-n-Provider lassen sich auch Informationen über den laufenden Prozess abrufen. Das folgende D-Beispielskript enthält einen profile-Prüfpunkt mit 1.001 Hertz, der zum Abrufen der aktuellen Priorität des angegebenen Prozesses dient:

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

Um das Beispielskript in Aktion zu sehen, geben Sie die folgenden Befehle in ein Fenster ein:

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

Führen Sie das D-Skript einen kurze Zeit lang in einem anderen Fenster aus. Dabei müssen Sie 12345 mit der PID ersetzen, die Ihr echo-Befehl zurückgegeben hat.

# dtrace -s ./profpri.d 12345
 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 

Diese Ausgabe zeigt die Verzerrung der Timesharing-Scheduling-Klasse. Da der Shell-Prozess auf der CPU in einer Warteschleife läuft, wird dessen Priorität vom System stetig herabgesetzt. Wenn der Shell-Prozess seltener laufen würde, käme ihm eine höhere Priorität zuteil. Das Ergebnis sehen Sie, wenn Sie in die wartende Shell Strg-C eingeben und das Skript erneut ausführen:

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

Geben Sie nun einige Zeichen in die Shell ein. Nach Beendigung des DTrace-Skripts erhalten Sie eine ähnliche Ausgabe wie in diesem Beispiel:

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

Da der Shell-Prozess nicht in einer Warteschleife auf der CPU gelaufen ist, sondern sich in Erwartung einer Benutzereingabe schlafen gelegt hatte, hat er, als er schließlich ausgeführt wurde, eine wesentlich höhere Priorität erhalten.