Examinez la sortie suivante de 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 |
La colonne pi de la sortie ci-dessus indique le nombre de pages chargées. Le fournisseur vminfo vous permet d'obtenir davantage d'informations sur la source de ces chargements de page, comme illustré dans l'exemple suivant :
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 |
La sortie indique qu'un processus associé au logiciel StarOfficeTM, soffice.bin, est responsable de la plupart des chargements de page. Pour vous faire une meilleure idée du comportement de soffice.bin dans la mémoire virtuelle, vous pouvez activer toutes les sondes vminfo. L'exemple suivant exécute dtrace(1M) tout en lançant le logiciel StarOffice :
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 |
L'exemple de script suivant fournit davantage d'informations sur le comportement en mémoire virtuelle du logiciel StarOffice pendant le démarrage :
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); }
Exécutez le script tout en lançant à nouveau le logiciel StarOffice. Créez ensuite un nouveau dessin, puis une nouvelle présentation, fermez tous les fichiers et quittez l'application. Appuyez sur Control-C dans le shell dans lequel le script D est exécuté. Les résultats fournissent un aperçu du comportement en mémoire virtuelle dans le temps :
# 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 |
La sortie montre un comportement de StarOffice en fonction du système de mémoire virtuelle. Par exemple, la sonde maj_fault ne s'est pas déclenchée avant le démarrage d'une nouvelle instance de l'application. Comme vous l'espériez, un “démarrage à chaud” de StarOffice n'a pas engendré de nouvelles défaillances majeures. La sortie de as_fault indique une hausse d'activité initiale, une latence pendant la localisation du menu par l'utilisateur pour créer un nouveau dessin, une autre période d'inactivité et un dernier pic d'activité lorsque l'utilisateur a cliqué sur une nouvelle présentation. La sortie de zfod indique que la création de la nouvelle présentation s'est traduite, pendant une courte période, par une importante pression pour les pages remplies de zéros.
La nouvelle itération de la recherche de DTrace dans cet exemple va dépendre du sens que vous souhaitez donner à votre exploration. Si vous souhaitez comprendre la source de la demande de pages remplies de zéros, vous pouvez regrouper ustack() avec l'activation de zfod. Vous souhaiterez peut-être établir un seuil pour les pages remplies de zéros et utiliser une action stop() destructrice pour interrompre le processus fautif lorsque le seuil est franchi. Cette approche doit vous permettre d'utiliser des outils de débogage plus conventionnels comme truss(1) ou mdb(1). Le fournisseur vminfo vous permet d'associer les statistiques résultant des outils conventionnels comme vmstat(1M) aux applications provoquant le comportement du système.