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.