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.