Por: Marcelo Fontes

 

1. Introdução

 

É bastante comum estarmos diante da situação em que o servidor congela e eventos precedentes ao tal congelamento são os eventos do System: 2020 ou 2019. Veja o que é necessário para que se possa indicar a real causa de um destes eventos e posterior travamento do servidor.

 

2. Cenário

 

Servidor deixa de responder. Não responde nem a ping, não conseguimos logar na console. Depois de reiniciar o servidor no botão, abrimos o event viewer e deparamos com este evento:

Descrição do Evento:

 

Identificação do evento 2019

Tipo: Erro

Fonte: Srv

Categoria: Nenhuma

Identificação do evento: 2019

Data: Data

Hora: Hora

Usuário: N/A

Computador: Computador

Descrição:

O servidor não pôde alocar a memória não paginável do sistema porque estava vazia.

 

No caso para evento 2020 basicamente temos o mesmo cenário porém para a memória “paginável”. Usaremos como ilustração área de memória “não paginável” para este artigo ou chamada em inglês de “nonpaged pool”

 

3. Conceito referente à área de “memória não paginável”

 

Esta área de memória do kernel é onde É Carregado código vital para o funcionamento do sistema operacional. Ela é tão vital que deve sempre estar residente em memória física, portanto nunca será paginada. Drivers tanto do sistema operacional, de hardware, assim como de softwares se utilizam destes recursos, e é aí que mora o perigo. O eventual mau funcionamento de algum driver poderá alocar memória e não liberar a mesma após código executado, de forma que a “área de memória não paginável” disponível chega a próximo de zero causando o travamento do servidor.

 

 

 

4. Troubleshooting

 

1- Confirmar se existe um vazamento de memória: Um log de performance monitor com o objeto Memória é o suficiente para identificar se existe vazamento ou não. Este log deve ser iniciado ao reiniciar o servidor até o momento em que o problema ocorreu.

2- Confirmar qual a origem do vazamento. A única forma de se identificar qual o driver que vaza memória é através de duas formas. Log gerado pela ferramenta poolmon, e ou análise de um dump de memória. Nenhuma das duas garante que se possa identificar o causador do problema, pois tudo que conseguimos monitorar é o consumo de “nonpaged pool” alocado pela Tag (marca de pool) que é definido no momento da compilação do driver. Exemplo:

 

Pool Non-Paged                                                            

Tag        Type      Allocs             Frees                Diff        Bytes     

         

TdLL      Nonp     225939            153572              72367   41681600

575

tdLL       Nonp     198823            134902              63921   36816704         

575

tdLL       Nonp    108768              74148               34620   19938880        

 575

File        Nonp    12415424          12384203          31221   5023328           

160

Ntfr        Nonp     63868               5327                 58541   3747616

 

 

A coluna Tag mostra a Tag que é definida pelo driver. Exemplo TdLL é identificada como sendo do redirecionador da Symantec. O valor em bytes é o quanto que esta Tag possue alocado no momento.

 

Para maior aprofundamento da análise necessitamos do dump de memória gerado via teclado, conforme documento abaixo:

 

244139          Windows feature lets you generate a memory dump file by using the keyboard

http://support.microsoft.com/default.aspx?scid=kb;EN-US;244139

 

A necessidade do dump se dá devido ao fato de muitas vezes, apesar de haver o vazamento causado por certa tag, como por exemplo NtFC que é gerada por NTFS.sys do windows, existe um causador indireto que faz com que NTFS aloque indefinidamente o montante de memória, como exemplo um “filter driver” que atua nos meandros entre NTFS e o disco.

 

Uma consideração deve ser feita, caso o sistema operacional seja anterior ao Windows Server 2003, nestes sistemas operacionais para que haja dados no log do poolmon, é necessário habilitar-se o pooltag. Veja documento abaixo:

 

177415          How to Use Memory Pool Monitor (Poolmon.exe) to Troubleshoot Kernel Mode Memory Leaks

http://support.microsoft.com/default.aspx?scid=kb;EN-US;177415

 

 

 

 

 

5. Conclusão

 

 

Novamente estamos recomendando o preparo do servidor para geração de um dump de memória para caso de troubleshooting de travamento de servidores, neste artigo introduzimos a ferramenta poolmon.exe como importante recurso para auxilio de problemas de esgotamento de recursos de kernel, paged pool e nonpaged pool.