Capítulo 37 Seguimiento postmortem
Este capítulo describe las funciones de DTrace para extracción y procesamiento postmortem de los datos del núcleo de los consumidores de DTrace. En caso de un bloqueo del sistema, la información registrada con DTrace podría proporcionar las pistas básicas para deducir la causa del fallo del sistema. Los datos de DTrace podrían extraerse y procesarse desde el volcado del bloqueo del sistema para ayudarle a comprender fallos de sistema fatales. Mediante la conjunción de estas funciones postmortem de DTrace con su directiva de memoria intermedia "introducción en memoria intermedia en anillo" (ring buffering), (consulte el Capítulo 11Memorias intermedias y almacenamiento en memoria intermedia), es posible utilizar DTrace como sistema operativo similar al dispositivo de registro de datos de vuelo conocido como la caja negra que podemos encontrar en los aviones comerciales.
Para extraer los datos de DTrace de un volcado de bloqueo de sistema determinado, debe empezar por ejecutar Solaris Modular Debugger, mdb(1), en el volcado por caída del sistema en cuestión. El módulo MDB que contenga la función DTrace se cargará automáticamente. Para obtener más información acerca de MDB, consulte la Solaris Modular Debugger Guide .
Visualización de consumidores de DTrace
Para extraer los datos de DTrace desde un consumidor de DTrace, primero debe determinar el consumidor de DTrace de interés mediante la ejecución del dcmd 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
|
Este comando muestra una tabla de las estructuras de estado de DTrace. Cada fila de la tabla contiene la siguiente información:
-
La dirección de la estructura de estado
-
El número menor asociado al dispositivo dtrace(7D)
-
La dirección de la estructura de proceso que corresponde al consumidor de DTrace
-
El nombre del consumidor de DTrace (o <anonymous> para los consumidores anónimos)
-
El nombre de la estructura de archivos que corresponde al dispositivo dtrace(7D) abierto
Para obtener más información acerca de un consumidor de DTrace en concreto, especifique la dirección de su estructura de procesos en el dcmd ::ps:
> d71377f0::ps S PID PPID PGID SID UID FLAGS ADDR NAME R 100647 100642 100647 100638 0 0x00004008 d71377f0 dtrace |
Visualización de datos de seguimiento
Una vez determine cuál es el consumidor de su interés, es posible recuperar los datos correspondientes a cualquier memoria intermedia mediante la especificación de la estructura de datos en el dcmd ::dtrace. El siguiente ejemplo muestra la salida del dcmd ::dtrace en una activación anónima de syscall:::entry con la acción 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
...
|
::dtrace dcmd maneja los errores de la misma forma que dtrace(1M): si se encuentran anulaciones, errores, anulaciones especulativas, etc., durante la ejecución del consumidor, ::dtrace emitirá un mensaje correspondiente al mensaje dtrace(1M).
El orden de los eventos tal y como lo muestra ::dtrace es siempre de más antiguo a más reciente dentro de una CPU determinada. Las memorias intermedias de la CPU se muestran en sí mismas en orden numérico. Si se requiere la ordenación de eventos de diferentes CPU, realice un seguimiento de la variable timestamp.
Puede visualizar sólo los datos de una CPU determinada especificando la opción - c a ::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 ... |
Tenga en cuenta que ::dtrace sólo procesa datos de DTrace del núcleo. Los datos que se hayan consumido desde el núcleo y se hayan procesado (mediante dtrace(1M) u otras vías) no estarán disponibles para su procesamiento con ::dtrace. Para garantizar que la máxima cantidad de datos posible esté disponible en el momento del error, utilice una directiva de memoria intermedia de "introducción en memoria en anillo" (ring buffering). Consulte el Capítulo 11Memorias intermedias y almacenamiento en memoria intermedia para obtener más información sobre las políticas de búfer.
Los siguientes ejemplos crean una memoria intermedia en anillo de tamaño muy reducido (16K) y registran todas las llamadas de sistema y los procesos que las realizan:
# dtrace -P syscall'{trace(curpsinfo->pr_psargs)}' -b 16k -x bufpolicy=ring
dtrace: description 'syscall:::entry' matched 214 probes
|
La observación de un volcado de bloqueo realizado mientras el comando anterior se encontraba en ejecución devolverá una salida similar a la del siguiente ejemplo:
> ::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
>
|
Tenga en cuenta que los registros más recientes de la CPU incluyen una serie de llamadas de sistema write(2) realizadas por un proceso mdb -kw. Probablemente, este resultado estará relacionado con el fallo del sistema, ya que un usuario puede ejecutar los datos o el texto del núcleo en ejecución con mdb(1) cuando se ejecuta con las opciones -k y - w. En este caso, los datos de DTrace proporcionan al menos una vía interesante de navegación, si no la causa raíz del fallo.
- © 2010, Oracle Corporation and/or its affiliates