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