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.
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 |
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.