Capítulo 37 Rastreio post-mortem
Este capítulo descreve os recursos do DTrace para extração e processamento post-mortem dos dados no kernel de consumidores do DTrace. No caso de um travamento do sistema, as informações que foram registradas com o DTrace podem fornecer dicas fundamentais para descobrir a causa da falha do sistema. Os dados do DTrace podem ser extraídos e processados do despejo de memória do sistema para ajudá-lo na compreensão de falhas graves do sistema. Ao unir esses recursos post-mortem do DTrace com sua política de armazenamento em buffer em anel (consulte o Capítulo 11Buffers e armazenamento em buffer), o DTrace pode ser usado como um sistema operacional semelhante à caixa preta, o gravador de dados de vôo existente na aviação comercial.
Para extrair dados do DTrace de um despejo de memória específico, você deve começar executando o Depurador modular Solaris, mdb(1), no despejo de memória de seu interesse. O módulo MDB que contém o recurso do DTrace será carregado automaticamente. Para aprender mais sobre o MDB, consulte o Solaris Modular Debugger Guide.
Exibindo consumidores do DTrace
Para extrair dados do DTrace de um consumidor do DTrace, você deve primeiro determinar o consumidor do DTrace desejado, executando o dcmd do 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 exibe uma tabela das estruturas de estado do DTrace. Cada linha da tabela consiste nas seguintes informações:
-
O endereço da estrutura de estado.
-
O número secundário associado ao dispositivo dtrace(7D)
-
O endereço da estrutura do processo que corresponde ao consumidor do DTrace.
-
O nome do consumidor do DTrace (ou <anonymous> dos consumidores anônimos).
-
O nome da estrutura do arquivo que corresponde ao dispositivo dtrace(7D) aberto.
Para obter mais informações sobre um consumidor específico do DTrace, especifique o endereço de sua estrutura de processo como o dcmd ::ps:
> d71377f0::ps S PID PPID PGID SID UID FLAGS ADDR NAME R 100647 100642 100647 100638 0 0x00004008 d71377f0 dtrace |
Exibindo dados de rastreio
Depois que você determinar o consumidor de seu interesse, poderá recuperar os dados correspondentes aos buffers não consumidos, especificando o endereço da estrutura do estado como o dcmd ::dtrace. O exemplo a seguir mostra o resultado do dcmd ::dtrace em uma habilitação anônima de syscall:::entry com a ação 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
...
|
O dcmd ::dtrace trata os erros da mesma maneira que o dtrace(1M): se eliminações, erros, eliminações especulativas ou similares forem encontrados durante a execução do consumidor, o ::dtrace emitirá uma mensagem correspondente à mensagem do dtrace(1M).
A ordem dos eventos exibidos por ::dtrace é sempre do mais antigo para o mais recente em uma determinada CPU. Os buffers da CPU são exibidos em ordem numérica. Se uma ordem for necessária para eventos em CPUs diferentes, rastreie a variável timestamp.
Você pode exibir somente os dados de uma determinada CPU, especificando a opção - c como ::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 ... |
Observe que ::dtrace processa somente dados do DTrace no kernel . Os dados que tenham sido consumidos no kernel e processados (através do dtrace(1M) ou outros meios) não estarão disponíveis para ser processados com o ::dtrace. Para garantir que a maior quantidade possível de dados esteja disponível no momento da falha, use uma política de armazenamento em buffer em anel. Consulte o Capítulo 11Buffers e armazenamento em buffer para obter mais informações sobre as políticas de buffer.
O exemplo a seguir cria um buffer em anel muito pequeno (16K) e registra todas as chamadas do sistema e o processo que as faz:
# dtrace -P syscall'{trace(curpsinfo->pr_psargs)}' -b 16k -x bufpolicy=ring
dtrace: description 'syscall:::entry' matched 214 probes
|
A observação de um despejo de memória obtido quando o comando acima estava sendo executado produz um resultado similar ao seguinte exemplo:
> ::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
>
|
Observe que os registros mais recentes da CPU 1 incluem uma série de chamadas do sistema de write(2) por um processo mdb -kw. Esse resultado provavelmente está relacionado ao motivo da falha do sistema porque um usuário pode modificar texto ou dados em execução no kernel com mdb(1) quando executados com as opções -k e - w. Nesse caso, os dados do DTrace fornecem pelo menos um meio interessante de investigação, se não a causa principal da falha.
- © 2010, Oracle Corporation and/or its affiliates