Beispiel
Betrachten Sie die folgende Ausgabe von vmstat(1M):
kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr cd s0 — — in sy cs us sy id 0 1 0 1341844 836720 26 311 1644 0 0 0 0 216 0 0 0 797 817 697 9 10 81 0 1 0 1341344 835300 238 934 1576 0 0 0 0 194 0 0 0 750 2795 791 7 14 79 0 1 0 1340764 833668 24 165 1149 0 0 0 0 133 0 0 0 637 813 547 5 4 91 0 1 0 1340420 833024 24 394 1002 0 0 0 0 130 0 0 0 621 2284 653 14 7 79 0 1 0 1340068 831520 14 202 380 0 0 0 0 59 0 0 0 482 5688 1434 25 7 68 |
Die Spalte pi in der obigen Ausgabe gibt die Anzahl der eingelagerten Seiten an. Der Provider vminfo bietet Ihnen die Möglichkeit, mehr über den Ursprung dieser Einlagerungen zu erfahren:
dtrace -n pgin'{@[execname] = count()}'
dtrace: description 'pgin' matched 1 probe
^C
xterm 1
ksh 1
ls 2
lpstat 7
sh 17
soffice 39
javaldx 103
soffice.bin 3065
|
Die Ausgabe zeigt, dass der mit der StarOfficeTM-Software verbundene Prozess soffice.bin für die meisten Seiteneinlagerungen verantwortlich ist. Um eine genauere Vorstellung von soffice.bin in Bezug auf das virtuelle Speicherverhalten zu erhalten, könnten wir nun alle vminfo-Prüfpunkte aktivieren. Im nächsten Beispiel wird dtrace(1M) beim Starten der StarOffice-Software ausgeführt:
dtrace -P vminfo'/execname == "soffice.bin"/{@[probename] = count()}'
dtrace: description 'vminfo' matched 42 probes
^C
kernel_asflt 1
fspgin 10
pgout 16
execfree 16
execpgout 16
fsfree 16
fspgout 16
anonfree 16
anonpgout 16
pgpgout 16
dfree 16
execpgin 80
prot_fault 85
maj_fault 88
pgin 90
pgpgin 90
cow_fault 859
zfod 1619
pgfrec 8811
pgrec 8827
as_fault 9495
|
Das folgende Beispielskript liefert zusätzliche Informationen über das virtuelle Speicherverhalten der StarOffice-Software während des Programmstarts:
vminfo:::maj_fault,
vminfo:::zfod,
vminfo:::as_fault
/execname == "soffice.bin" && start == 0/
{
/*
* This is the first time that a vminfo probe has been hit; record
* our initial timestamp.
*/
start = timestamp;
}
vminfo:::maj_fault,
vminfo:::zfod,
vminfo:::as_fault
/execname == "soffice.bin"/
{
/*
* Aggregate on the probename, and lquantize() the number of seconds
* since our initial timestamp. (There are 1,000,000,000 nanoseconds
* in a second.) We assume that the script will be terminated before
* 60 seconds elapses.
*/
@[probename] =
lquantize((timestamp - start) / 1000000000, 0, 60);
}
Führen Sie das Skript aus, während Sie die StarOffice-Software noch einmal starten. Erstellen Sie dann eine neue Zeichnung und eine neue Präsentation, schließen Sie alle Dateien und beenden Sie die Anwendung. Drücken Sie in der Shell, in der das D-Skript ausgeführt wird, Strg-C. Die Ergebnisse gewähren uns einen Einblick in das virtuelle Speicherverhalten im Verlauf der Zeit.
# dtrace -s ./soffice.d
dtrace: script './soffice.d' matched 10 probes
^C
maj_fault
value ------------- Distribution ------------- count
7 | 0
8 |@@@@@@@@@ 88
9 |@@@@@@@@@@@@@@@@@@@@ 194
10 |@ 18
11 | 0
12 | 0
13 | 2
14 | 0
15 | 1
16 |@@@@@@@@ 82
17 | 0
18 | 0
19 | 2
20 | 0
zfod
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@@@@@ 525
1 |@@@@@@@@ 605
2 |@@ 208
3 |@@@ 280
4 | 4
5 | 0
6 | 0
7 | 0
8 | 44
9 |@@ 161
10 | 2
11 | 0
12 | 0
13 | 4
14 | 0
15 | 29
16 |@@@@@@@@@@@@@@ 1048
17 | 24
18 | 0
19 | 0
20 | 1
21 | 0
22 | 3
23 | 0
as_fault
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@@@@@@@@@@@ 4139
1 |@@@@@@@ 2249
2 |@@@@@@@ 2402
3 |@ 594
4 | 56
5 | 0
6 | 0
7 | 0
8 | 189
9 |@@ 929
10 | 39
11 | 0
12 | 0
13 | 6
14 | 0
15 | 297
16 |@@@@ 1349
17 | 24
18 | 0
19 | 21
20 | 1
21 | 0
22 | 92
23 | 0
|
Die Ausgabe zeigt einen Teil des StarOffice-Verhaltens in Bezug auf das virtuelle Speichersystem. So wurde beispielsweise der Prüfpunkt maj_fault erst ausgelöst, als eine neue Instanz der Anwendung gestartet wurde. Wie zu erhoffen war, hat der „Warmstart“ von StarOffice keine neuen größeren Seitenfehler verursacht. Die Ausgabe von as_fault zeigt ein anfängliches Aktivitätshoch, eine gewisse Latenz, während der Benutzer das Menü zum Erstellen einer neuen Zeichnung sucht, eine weitere Leerlaufzeit und schließlich ein Aktivitätshoch, als der Benutzer auf eine neue Präsentation klickt. Die Ausgabe von zfod zeigt, dass das Erstellen der neuen Präsentation über einen kurzen Zeitraum einen starken Bedarf an mit Nullen gefüllten Seiten bewirkt hat.
Der nächste Schritt in der DTrace-Nachforschung für dieses Beispiel hängt von der einzuschlagenden Richtung ab. Wenn Sie verstehen möchten, woher der Bedarf an mit Nullen gefüllten Seiten kommt, könnten Sie ustack() in einer zfod-Aktivierung aggregieren. Es bietet sich an, einen Schwellwert für die mit Nullen gefüllten Seiten festzulegen und den verletzenden Prozess durch die destruktive Aktion stop() anhalten zu lassen, wenn der Schwellwert überschritten wird. Dieser Ansatz würde die Verwendung eher herkömmlicher Debugging-Tools wie truss(1) oder mdb(1). Der Provider vminfo macht es möglich, die statistischen Daten in den Ausgaben herkömmlicher Tools wie vmstat(1M) mit den Anwendungen in Verbindung zu bringen, die das systemische Verhalten verursachen.
- © 2010, Oracle Corporation and/or its affiliates