Affichage de données de suivi
Une fois le client déterminé, vous pouvez récupérer les données correspondant à tous les tampons non consommés en indiquant l'adresse de la structure d'état dans la commande ::dtrace. L'exemple suivant illustre la sortie de la commande ::dtrace sur une activation anonyme de syscall:::entry avec l'action trace(execname) :
> ::dtrace_state
ADDR MINOR PROC NAME FILE
cbfb7a40 2 - <anonymous> -
> cbfb7a40::dtrace
CPU ID FUNCTION:NAME
0 344 resolvepath:entry init
0 16 close:entry init
0 202 xstat:entry init
0 202 xstat:entry init
0 14 open:entry init
0 206 fxstat:entry init
0 186 mmap:entry init
0 186 mmap:entry init
0 186 mmap:entry init
0 190 munmap:entry init
0 344 resolvepath:entry init
0 216 memcntl:entry init
0 16 close:entry init
0 202 xstat:entry init
0 14 open:entry init
0 206 fxstat:entry init
0 186 mmap:entry init
0 186 mmap:entry init
0 186 mmap:entry init
0 190 munmap:entry init
...
|
La commande ::dtrace gère les erreurs comme dtrace(1M) : si des dépôts, des erreurs, des dépôts de spéculation ou similaires sont rencontrés pendant l'exécution du consommateur, ::dtrace renvoie un message correspondant au message dtrace(1M).
L'ordre des événements affichés par ::dtrace est toujours du plus ancien au plus récent pour une CPU donnée. Les tampons de la CPU s'affichent par ordre numérique. Si des événements de différentes CPU doivent être classés, suivez la variable timestamp.
Vous ne pouvez afficher que les données d'une CPU spécifique en indiquant l'option - c pour ::dtrace :
> cbfb7a40::dtrace -c 1 CPU ID FUNCTION:NAME 1 14 open:entry init 1 206 fxstat:entry init 1 186 mmap:entry init 1 344 resolvepath:entry init 1 16 close:entry init 1 202 xstat:entry init 1 202 xstat:entry init 1 14 open:entry init 1 206 fxstat:entry init 1 186 mmap:entry init ... |
Notez que ::dtrace ne traite que les données DTrace du noyau. Les données consommées depuis le noyau et traitées (via dtrace(1M) ou autres) ne peuvent pas être traitées avec ::dtrace. Pour s'assurer qu'une majorité de données soit disponible au moment d'une panne, utilisez une stratégie de mise en tampon. Pour plus d'informations sur les stratégies de tampon, reportez-vous au Chapitre11Tampons et mise en tampon.
L'exemple suivant crée un tampon de très petite taille (16 K) et enregistre tous les appels système et le processus de leur création :
# dtrace -P syscall'{trace(curpsinfo->pr_psargs)}' -b 16k -x bufpolicy=ring
dtrace: description 'syscall:::entry' matched 214 probes
|
Supposons un vidage de panne lors de l'exécution de la commande ci-dessus ; les résultats sont similaires à l'exemple suivant :
> ::dtrace_state
ADDR MINOR PROC NAME FILE
cdccd400 3 d15e80a0 dtrace ced065f0
> cdccd400::dtrace
CPU ID FUNCTION:NAME
0 139 getmsg:return mibiisa -r -p 25216
0 138 getmsg:entry mibiisa -r -p 25216
0 139 getmsg:return mibiisa -r -p 25216
0 138 getmsg:entry mibiisa -r -p 25216
0 139 getmsg:return mibiisa -r -p 25216
0 138 getmsg:entry mibiisa -r -p 25216
0 139 getmsg:return mibiisa -r -p 25216
0 138 getmsg:entry mibiisa -r -p 25216
0 139 getmsg:return mibiisa -r -p 25216
0 138 getmsg:entry mibiisa -r -p 25216
0 17 close:return mibiisa -r -p 25216
...
0 96 ioctl:entry mibiisa -r -p 25216
0 97 ioctl:return mibiisa -r -p 25216
0 96 ioctl:entry mibiisa -r -p 25216
0 97 ioctl:return mibiisa -r -p 25216
0 96 ioctl:entry mibiisa -r -p 25216
0 97 ioctl:return mibiisa -r -p 25216
0 96 ioctl:entry mibiisa -r -p 25216
0 97 ioctl:return mibiisa -r -p 25216
0 16 close:entry mibiisa -r -p 25216
0 17 close:return mibiisa -r -p 25216
0 124 lwp_park:entry mibiisa -r -p 25216
1 68 access:entry mdb -kw
1 69 access:return mdb -kw
1 202 xstat:entry mdb -kw
1 203 xstat:return mdb -kw
1 14 open:entry mdb -kw
1 15 open:return mdb -kw
1 206 fxstat:entry mdb -kw
1 207 fxstat:return mdb -kw
1 186 mmap:entry mdb -kw
...
1 13 write:return mdb -kw
1 10 read:entry mdb -kw
1 11 read:return mdb -kw
1 12 write:entry mdb -kw
1 13 write:return mdb -kw
1 96 ioctl:entry mdb -kw
1 97 ioctl:return mdb -kw
1 364 pread64:entry mdb -kw
1 365 pread64:return mdb -kw
1 366 pwrite64:entry mdb -kw
1 367 pwrite64:return mdb -kw
1 364 pread64:entry mdb -kw
1 365 pread64:return mdb -kw
1 38 brk:entry mdb -kw
1 39 brk:return mdb -kw
>
|
Notez que les enregistrements les plus récents de la CPU 1 comprennent une série d'appels système write(2) selon un processus mdb -kw. Ce résultat est probablement lié au motif de la panne système car un utilisateur peut modifier des données ou du texte du noyau en cours d'exécution avec mdb(1) lors d'une exécution avec les options -k et -w. Dans ce cas, les données DTrace fournissent au moins un élément de recherche intéressant, sinon le motif principal de la panne.
- © 2010, Oracle Corporation and/or its affiliates