Se acontecer o inesperado e o sistema operacional IBM AIX® travar, o melhor é que as informações sejam reunidas automaticamente. Com o uso de dispositivos de dump, o core dump é colocado nesses dispositivos, pronto para ser transferido para o suporte IBM.

David Tansley, System Administrator, Ace Europe

David TansleyDavid Tansley é escritor freelance. Ele possui 15 anos de experiência como administrador UNIX, usando AIX nos últimos oito anos. Gosta de jogar badminton e relaxar assistindo à Fórmula 1, mas nada é melhor que passear em sua moto GSA com sua esposa.


nível de autor Contribuidor do
        developerWorks

16/Jul/2012

Introdução

Se um sistema trava devido a um evento inesperado, ele realiza um core dump. Aliás, um core dump pode ocorrer sem travamento. No entanto, para este artigo, eu estou supondo que o sistema fica indisponível devido a um evento fatal ou a uma ação forçada do usuário. O dump contém o conteúdo da memória até o ponto do travamento. Travamentos são, por sua própria natureza, inesperados, portanto cabe ao administrador do sistema preparar-se antecipadamente para caso isso aconteça. É possível saber que um travamento ocorreu porque o sistema reinicializou e há entradas no log de erro com o rótulo: SYSDUMP.

Para esta demonstração, estou usando AIX 7.1. No entanto, os princípios discutidos se aplicam também ao AIX 5.3 e 6.1.


Preparar-se, preparar-se

Para se preparar para o inesperado travamento do sistema, é necessário ter um volume lógico (LV) de dispositivo de dump no qual o dump é colocado quando o sistema retorna. No entanto, se esse dispositivo de dump não estiver disponível, um dispositivo secundário deverá ser designado para conter o dump. Pode acontecer de os responsáveis não se importarem com os travamentos do sistema e não se interessarem em investigar melhor o arquivo de dump. Isso cabe apenas ao proprietário do sistema. Mas lembre-se que ter um dispositivo de dump primário presente no rootvg é uma boa prática e um requisito para que o sistema funcione corretamente. O dispositivo de dump pode ser espelhado, mas o suporte do IBM AIX recomenda cuidado com isso. Isso porque um travamento pode estar relacionado ao espelhamento ou sincronização, o que invalida o espelhamento do dispositivo de dump. Em algumas circunstâncias, o arquivo dump pode ser copiado apenas para uma das cópias do dispositivo de dump espelhado, que reside nos discos espelhados. Pode acontecer de apenas metade da cópia do arquivo dump ser recuperada quando o sistema for reiniciado. Uma boa prática é colocar o dispositivo de dump primário em um disco, sem espelhamento, e o dispositivo secundário no outro disco, sem espelhamento. No entanto, eu descobri que é comum espelhar o dispositivo de dump de rootvg. O dispositivo de dump secundário pode estar dentro ou fora do rootvg, desde que não esteja em um espaço de paginação ou em um dispositivo externo (por exemplo, um dispositivo de fita).


Dispositivos de dump

Tradicionalmente, o dispositivo de dump padrão para dumps do sistema era /dev/hd6 (espaço de paginação) e ainda é em muitos sistemas. Se não houver espaço suficiente para copiar o arquivo dump após um travamento, é solicitado ao administrador do sistema, na reinicialização, que copie o arquivo dump para uma mídia removível, como uma fita ou DVD. Isso pode ser demorado, e às vezes o administrador quer o sistema de volta rapidamente. Eu compreendo os administradores de sistema que simplesmente ignoram a solicitação para que o sistema retorne devido à pressão dos negócios, excluindo assim o dump, de modo que ninguém sabe por que o travamento ocorreu. Se não houver espaço suficiente no dispositivo de dump para copiar o dump, o utilitário de menu copydumpmenu será chamado, durante o processo de inicialização, para que o administrador do sistema possa copiar o dump para uma mídia removível (por exemplo, um dispositivo de fita, se houver). O utilitário copydumpmenu também pode ser chamado na linha de comandos quando o sistema estiver disponível. O diretório de cópia padrão é /var/adm/ras, com o nome de arquivo vmcore.<X>.BZ, no qual X é um número sequencial. O arquivo dump tem o formato de compactação BZ (BZIP) e não Z.

O comando snap pode ser usado para reunir informações sobre o arquivo dump. Não deixe de incluir o sinalizador -D, que coleta informações do dispositivo de dump primário.

Como os sistemas agora possuem mais memória disponível, há uma maior flexibilidade para colocação do dispositivo de dump primário. Geralmente, para sistemas com mais de 4 GB de memória, há agora um dispositivo de dump dedicado, chamado: lg_dumplv

# lsvg -l rootvg |grep sysdump
lg_dumplv sysdump  8  8   open/syncd N/A

Com o comando sysdumpdev, é possível determinar quais dispositivos são usados para os dumps do sistema.

A saída a seguir mostra um sistema usando AIX 7.1 com lg_dumplv como seu dispositivo de dump primário:

#  sysdumpdev -l
primary              /dev/lg_dumplv
secondary            /dev/sysdumpnull
copy directory       /var/adm/ras
forced copy flag     TRUE
always allow dump    TRUE
dump compression     ON
type of dump         traditional

Observando melhor os campos de saída acima. Observe que um campo extra está presente agora a partir do AIX 6.1: type of dump. Atualmente configurado como tradicional, é possível configurá-lo para auxiliado por firmware se o hardware suportar. Para o campo secundário, não há dispositivo de dump. Isso é indicado pelo uso do dispositivo sysdumpnull. Isso significa que todos os dumps do sistema são perdidos se forem para esse dispositivo. O diretório de cópia é /var/adm/ras. É nesse diretório que o dump do sistema será copiado, para análise posterior ou para ser enviado ao suporte IBM. Observe que "always allow dump" está configurado como verdadeiro. Isso é necessário para que um dump seja iniciado com sucesso. A compactação de dumps está ativada por padrão.

Algumas configurações comuns usando sysdumpdev:

  • Para alterar o dispositivo primário, use: sysdumpdev -P -p <device_name>
  • Para alterar o dispositivo secundário, use: sysdumpdev -P -s <device_name>
  • Para alterar o diretório de cópia, use: sysdumpdev -D <path_name>
  • Para alterar a condição de sempre realizar dump ("always dump"), use: sysdumpdev -k para falso, sysdumpdev -K para verdadeiro
  • Para alterar o tipo de dump, use: sysdumpdev -t <fw-assisted | traditional>

Dump do sistema controlado pelo usuário

Para iniciar um dump (o que reinicia o sistema como parte do processo), use o comando sysdumpstart. O comando a seguir usa o dispositivo primário para colocar seu dump:

# sysdumpstart -p

Quando esse processo é iniciado, o painel LED do sistema ou tela HMC no meu Power 5 exibe 00c2. Isso indica que o dump está em andamento. Após a reinicialização do sistema de boot, o log de erro pode conter as seguintes entradas:

# errpt |more
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
A6DF45AA   1027180611 I O RMCdaemon      The daemon is started.
67145A39   1027180411 U S SYSDUMP        SYSTEM DUMP
F48137AC   1027180411 U O minidump       COMPRESSED MINIMAL DUMP
A6DF45AA   1027180411 I O RMCdaemon      The daemon is started.
9DBCFDEE   1027180511 T O errdemon       ERROR LOGGING TURNED ON

Uma investigação maior do relatório de erro declara:

Type:            UNKN
WPAR:            Global
Resource Name:   SYSDUMP

Description
SYSTEM DUMP

Probable Causes
UNEXPECTED SYSTEM HALT

User Causes
SYSTEM DUMP REQUESTED BY USER

        Recommended Actions
        PERFORM PROBLEM DETERMINATION PROCEDURES

Failure Causes
UNEXPECTED SYSTEM HALT
        Recommended Actions
        PERFORM PROBLEM DETERMINATION PROCEDURES

Detail Data
DUMP DEVICE
/dev/lg_dumplv
DUMP SIZE
              63894528
TIME
Thu Oct 27 18:02:28 2011
DUMP TYPE (1 = PRIMARY, 2 = SECONDARY)
           1
DUMP STATUS
           0

Ao olhar para a saída acima, sabemos que o dump foi para o dispositivo de dump primário.

O comando sysdumpdev a seguir também confirma que o dump ocorreu no dispositivo primário. Também são exibidas informações sobre a data, tamanho, nome do dispositivo e se o dump teve sucesso ou não:

# sysdumpdev -L
0453-039

Device name:         /dev/lg_dumplv
Major device number: 10
Minor device number: 16
Size:                63894528 bytes
Uncompressed Size:   498002880 bytes
Date/Time:           Thu Oct 27 18:02:28 BST 2011
Dump status:         0
Type of dump:        traditional
dump completed successfully

O seguinte comando também informará sobre o dump do sistema mais recente, seu tamanho e localização:

# sysdumpdev -z
63894528 /dev/lg_dumplv

Agora o dump compactado está no LV lg_dumplv. O dump não foi copiado para o diretório de cópia quando o dump iniciado pelo usuário foi emitido. Para copiar o dump do sistema mais recente de um dispositivo de dump do sistema para um diretório, use o comando savecore. Por exemplo, para copiar o dump para o diretório /var/adm/ras. Eu poderia usar:

# savecore -d /var/adm/ras
vmcore.0.BZ

Se for necessário descompactar o arquivo, use o utilitário dmpuncompress. O formato do comando é:

dmpuncompress  < filename>

Após a descompactação, o arquivo dump está pronto para investigação usando kdb ou para transferência para o suporte IBM.

# dmpuncompress vmcore.0.BZ
replaced with vmcore.0

Como alternativa, também é possível usar a opção de menu smit dump e selecionar Copy a system dump. A tela a seguir é exibida:

                              Copy dump image to:

Type or select values in entry fields.
Press Enter after making all desired changes.

                                                        [Entry Fields]
* Copy dump image from:                              [/dev/lg_dumplv]         /
* Copy dump image to:                                [/var/adm/ras/dump_fil>
* Input and output file blocksize for copy           [4096]                   #
  Size in bytes of dump image                         63894528
  Date of last dump                                   Thu Oct 27 18-02-28 B>

Esses campos são preenchidos com o dump atual que está no dispositivo de dump primário. Essa é a configuração padrão. Após a cópia, o arquivo estará presente em /var/adm/ras:

# ls -l dump_file_copy.BZ
-rw-r--r--    1 root     system     63894528 Oct 27 18:15 dump_file_copy.BZ

Após ocorrer um dump, também pode ser gerado um minidump. Na saída do log de erro anterior do artigo, havia uma entrada para:

F48137AC   1027180411 U O minidump       COMPRESSED MINIMAL DUMP

O minidump é um pequeno dump compactado que se localiza em /var/adm/ras. Esse arquivo contém uma captura instantânea do sistema quando ocorreu o dump ou travamento. Esse arquivo pode ser usado para diagnóstico se o dump principal não estiver presente por ter sido removido ou por não ter sido capturado.


Criando um dispositivo secundário

Anteriormente nesta demonstração, na saída de "sysdumpdev -l", o dispositivo de dump secundário estava configurado como /dev/sysdumpnull. Isso significa que um dump será perdido se for para esse dispositivo secundário. Ele se comporta de forma semelhante ao dispositivo NULL. Tudo que vai para ele vai direto para a lixeira. Agora irei criar um dispositivo secundário e alterar os atributos de sydumpdev para refletir essa nova mudança. Assim eu posso estar seguro de que, se meu primeiro dispositivo de dump está disponível, o dump vai para o dispositivo secundário.

Nesta demonstração, o dispositivo primário usa oito partições lógicas (como mostrado na saída anterior). Portanto essa é a quantidade que criarei para o dispositivo secundário. No entanto, mostrarei primeiro as ações necessárias para dimensionar um dispositivo de dump.

Primeiro, precisamos saber qual é o tamanho potencial do dump que o AIX geraria, e depois usamos esse número como base para criar o dispositivo. O comando sysdumpdev com a opção "e" retorna uma estimativa do tamanho necessário. É melhor executar isso quando o sistema estiver em uso normal e não inativo:

# sysdumpdev -e
0453-041 Estimated dump size in bytes: 282486374

Observe que, se a compactação está ligada, o número de bytes retornado por sysdumpdev é para um dump compactado e não um tamanho de arquivo descompactado. O comando anterior retorna 282486374 bytes. Para ficar mais fácil, vamos converter esse número para MB:

#  expr 282486374 / 1024 / 1024
269

Em seguida, inclua aproximadamente 50% (cerca de 135 MB) para acomodar o caso de um travamento com o sistema sobrecarregado, o que dá um total de 404 MB. Esse é o número que estabelecerei como mínimo ao criar o dispositivo de dump. Observe também que o sistema de arquivo no qual ele será copiado precisa ter ao menos essa quantidade de espaço livre, ou a cópia irá falhar.

Primeiro, certifique-se de que o dispositivo primário, lg_dumplv, não está espelhado em rootvg e está residindo apenas em um disco. O disco secundário pode então ser colocado no outro disco. Pela saída a seguir, podemos determinar que essa é a única cópia de lg_dumplv:

# lsvg -l rootvg
rootvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
hd5                 boot       1       2       2    closed/syncd  N/A
…
...
livedump            jfs2       2       4       2    open/syncd    /var/adm/ras/livedump
lg_dumplv           sysdump    8       8       1    open/syncd    N/A

Em seguida, consulte o LV lg_dumplv para ver em qual disco ou discos ele reside. Pela saída a seguir, podemos ver que lg_dumplv reside apenas em hdisk0. Portanto, tudo está certo. Agora o dispositivo secundário pode ser criado, residindo no disco rootvg: hdisk1.

# lslv -m lg_dumplv
lg_dumplv:N/A
LP    PP1  PV1               PP2  PV2               PP3  PV3
0001  0008 hdisk0
0002  0009 hdisk0
0003  0010 hdisk0
0004  0011 hdisk0
0005  0012 hdisk0
0006  0013 hdisk0
0007  0014 hdisk0
0008  0015 hdisk0

Para determinar quantas partições lógicas (LP) devem ser usadas para criar o dispositivo secundário, consulte o grupo de volumes rootvg e observe o tamanho de PP. Na saída a seguir, o tamanho é de 128 MB.

# lsvg rootvg
VOLUME GROUP:       rootvg                   VG IDENTIFIER:  00c23bed00004c00000
0013142b3b106
VG STATE:           active                   PP SIZE:        128 megabyte(s)
VG PERMISSION:      read/write               TOTAL PPs:      270 (34560 megabyte
…
…

Portanto, para criar um LV de ao menos 404 MB, seriam necessárias quatro partições (o LV teria um tamanho de 512 MB). O comando para criar o LV é mklv. O formato básico para um tipo de dump do sistema usando o comando mklv é:

mklv -t sysdump -y <LV name> < volume group> < number of LP's> <hdisk to reside on>

Suponha o seguinte:

  • O LV se chama lg_dumplv2
  • Ele reside em hdisk1
  • É criado com quatro partições

O comando a seguir deve ser executado para criar o LV:

# mklv -t sysdump -y lg_dumplv2 rootvg  4 hdisk1

No entanto, como discutido anteriormente, o dispositivo secundário nesta demonstração é criado com o mesmo número de partições do dispositivo primário atual, que é oito. O comando a seguir faz isso, com hdisk e o nome do LV iguais ao do comando mklv executado anteriormente:

# mklv -t sysdump -y lg_dumplv2 rootvg 8 hdisk1

Primeiro, para confirmar que foi de fato criado em hdisk1, consulte o LV lg_dumplv2:

# lslv -m lg_dumplv2
lg_dumplv2:N/A
LP    PP1  PV1               PP2  PV2               PP3  PV3
0001  0003 hdisk1
0002  0004 hdisk1
0003  0005 hdisk1
0004  0006 hdisk1
0005  0007 hdisk1
0006  0008 hdisk1
0007  0009 hdisk1
0008  0010 hdisk1

Embora o LV tenha sido criado, ele não está ativo, mas sim em um estado encerrado. É possível ver isso ao visualizar os LVs contidos em rootvg:

#  lsvg -l rootvg
rootvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
hd5                 boot       1       2       2    closed/syncd  N/A
hd8                 jfs2log    1       2       2    open/syncd    N/A
…
…
lg_dumplv           sysdump    8       8       1    open/syncd    N/A
lg_dumplv2          sysdump    8       8       1    closed/syncd  N/A

Então a próxima tarefa é ativá-lo. Para isso, nós o designamos como o dispositivo secundário usando o comando sysdumpdev conforme descrito anteriormente:

# sysdumpdev -Ps /dev/lg_dumplv2
primary              /dev/lg_dumplv
secondary            /dev/lg_dumplv2
copy directory       /var/adm/ras
forced copy flag     TRUE
always allow dump    TRUE
dump compression     ON
type of dump         traditional

Em seguida consulte rootvg, para ver se está ativo:

#  lsvg -l rootvg
rootvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
hd5                 boot       1       2       2    closed/syncd  N/A
hd8                 jfs2log    1       2       2    open/syncd    N/A
…
…
lg_dumplv           sysdump    8       8       1    open/syncd    N/A
lg_dumplv2          sysdump    8       8       1    open/syncd    N/A

Tudo parece correto. Agora, para testar, inicie um dump do sistema no dispositivo secundário:

#  sysdumpstart -s

Para confirmar se o dump do sistema foi para o dispositivo secundário, após a inicialização, consulte sysdumpdev para ver onde reside o dump do sistema mais recente:

# sysdumpdev -L
0453-039

Device name:         /dev/lg_dumplv2
Major device number: 10
Minor device number: 18
Size:                64955392 bytes
Uncompressed Size:   502517142 bytes
Date/Time:           Thu Oct 27 18:19:37 BST 2011
Dump status:         0
Type of dump:        traditional
dump completed successfully

Como se pode ver na saída anterior, o dump foi para o dispositivo secundário.

Agora o comando savecore pode ser usado para copiar o dump mais recente para um diretório, para investigação ou transferência para fora do sistema.

# savecore -d /var/adm/ras
vmcore.0.BZ

Conclusão

Quando o sistema trava, você deve ter um registro dos eventos até o travamento. Ter dispositivos de dump para coletar essas informações deixa você em boa posição ao ligar para a IBM, pois terá um registro dos eventos antes do travamento.

Recursos

Centro de Controle do AIX v 7.1:

http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp

Recursos

Aprender

Obter produtos e tecnologias

  • Experimente o software IBM do ZK. Faça o download de uma versão de teste, faça login em uma versão de teste online, trabalhe com o produto em um ambiente de simulação ou acesse-o por meio da nuvem. Escolha dentre mais de 100 versões de avaliação de produtos IBM.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java, Software livre
ArticleID=824875
ArticleTitle=Entendendo Dispositivos de Dump
publish-date=07162012