Chapitre 37 Suivi post-mortem
Ce chapitre décrit les fonctionnalités DTrace pour l'extraction et le traitement post-mortem des données du noyau de clients DTrace. En cas de panne système, les informations enregistrées avec DTrace peuvent fournir des indices essentiels sur le motif principal de la panne. Des données DTrace peuvent être extraites et traitées du vidage de panne système pour vous aider à comprendre les pannes système fatales. En associant ces fonctionnalités post-mortem de DTrace avec sa stratégie de mise en tampon circulaire (voir Chapitre11Tampons et mise en tampon), DTrace peut servir de système d'exploitation analogue à l'enregistreur de données de vol de la boîte noire présent dans les avions commerciaux.
Pour extraire des données DTrace d'un vidage de panne spécifique, vous devez tout d'abord exécuter Solaris Modular Debugger, mdb(1), sur le vidage de panne concerné. Le module MDB contenant les fonctions est chargé automatiquement. Pour en savoir plus sur MDB, reportez-vous au document Solaris Modular Debugger Guide .
Affichage de clients DTrace
Pour extraire des données DTrace d'un client DTrace, vous devez tout d'abord déterminer le client DTrace concerné en exécutant la commande MDB ::dtrace_state :
> ::dtrace_state
ADDR MINOR PROC NAME FILE
ccaba400 2 - <anonymous> -
ccab9d80 3 d1d6d7e0 intrstat cda37078
cbfb56c0 4 d71377f0 dtrace ceb51bd0
ccabb100 5 d713b0c0 lockstat ceb51b60
d7ac97c0 6 d713b7e8 dtrace ceb51ab8
|
Cette commande affiche un tableau de structures d'état DTrace. Chaque ligne du tableau contient les informations suivantes :
-
l'adresse de la structure d'état ;
-
le nombre inférieur associé au périphérique dtrace(7D) ;
-
l'adresse de la structure de processus correspondant au client DTrace ;
-
le nom du client DTrace (ou <anonymous> pour les clients anonymes) ;
-
le nom de la structure de fichiers correspondant au périphérique dtrace(7D) ouvert.
Pour plus d'informations sur un client DTrace spécifique, indiquez l'adresse de sa structure de processus dans la commande ::ps :
> d71377f0::ps S PID PPID PGID SID UID FLAGS ADDR NAME R 100647 100642 100647 100638 0 0x00004008 d71377f0 dtrace |
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