Uma das ferramentas mais populares na coleta de dumps de memória é o Debug Diag. Atualmente na versão 2.1, este utilitário permite que a coleta de dumps seja feita em um formato mais completo, sem perda de informações relevantes.

Uma das principais vantagens do uso do Debug Diag é a coleta de dumps a partir de triggers.

Como apresentado na imagem abaixo, podemos notar que o Debug Diag nos fornece três regras básicas para a criação de triggers coletoras de dumps de memória.

Basicamente essas três regras funcionam da seguinte maneira:

– Crash (Código gerenciado): regra ativada quando um processo com código gerenciado lança uma exceção.

– Performance (Código gerenciado): regra ativada quando o consumo de recursos computacionais de um processo com código gerenciado atinge um limiar de performance configurado (seja esse recurso computacional memória, CPU ou até mesmo tempo de resposta de uma requisição HTTP).

– Native Memory and Handle Leak (Código não-gerenciado): como o nome já diz, essa regra será ativada quando um processo com código não-gerenciado consumir mais memória do que o esperado ou seu consumo de handles estiver acima de um limiar recomendado.

Neste post trataremos de dois cenários comuns: captura de dump de memória após o crash em aplicações web hosteadas no IIS (User Crash) e captura de dump de memória após lentidão na execução de uma requisição HTTP (Long HTTP Response Time).

Para a execução destes exemplos criei uma aplicação ASP.NET Web Forms e a publiquei no IIS, dentro de um website chamado ‘WebExceptionThrower’ com um application pool dedicado, também chamado de ‘WebExceptionThrower’.

Essa aplicação web consiste de uma única página com dois botões. Cada botão contém código para estimular os exemplos que queremos exercitar.

User Crash

Para o exemplo de captura de dump a partir de um User Crash, adicionei um código que forçasse o estouro de uma exceção. O quadro a seguir exemplifica o código utilizado.

protected void UserCrashButton_Click(object sender, EventArgs e) {

    int a = 0;
    int b = 10;

    double c = b / a;
}

A exceção gerada a partir deste erro é uma ‘System.DivideByZeroException’. O tipo da exceção lançada já nos diz muito, pois podemos filtrar pelo Debug Diag o tipo de erro que queremos analisar.

Voltando ao Debug Diag, devemos selecionar a primeira regra: Crash. Na próxima janela selecionamos a aplicação/processo que tem gerado a exceção. Neste exemplo, como temos uma aplicação hosteada no IIS, selecionaremos a opção ‘A specific IIS web application pool’.

Note que todos os application pools existentes no IIS serão listados. Selecione o application pool desejado. Neste exemplo selecionaremos o application pool ‘WebExceptionThrower’.

Na próxima janela iremos configurar a coleta dos dumps de memória. Siga as seguintes instruções para configurar o Debug Diag para coleta de dumps de exceções do tipo ‘System.DivideByZeroException’:

1 – No campo ‘Action type for unconfigured first chance exceptions’ selecione ‘Full user dump’

2 – No campo ‘Action limit for unconfigured first chance exceptions’ configure para ‘3’

3 – Clique em ‘Exceptions…’ e siga as seguintes configurações:

4 – Clique em ‘Add Exception…’

5 – Selecione ‘CLR (.NET) 4.x Exception’

5.1 – No campo ‘Exeption Type Equals’ informe ‘System.DivideByZeroException’

5.2 – No campo ‘Action Type’ selecione ‘Full Userdump’

5.3 – No campo ‘Action Limite’ configure para ‘3’

Clicando em ‘Ok’, sua janela deve se parecer com a imagem a seguir.

Clicando em ‘Save & Close’, sua janela deve se parecer com a imagem a seguir.

Cliquem em ‘Next’, atribua um nome para a regra criada e um diretório de destino para os dumps de memória. Após clicar em ‘Next’, marque a opção ‘Activate the rule now’ e clique em ‘Finish’.

Volte a aplicação e simule o erro. Você notará que o Debug Diag possui uma coluna chamada ‘Userdump Count’, essa coluna exibe quantos dumps de memória foram capturados durante a execução da regra.

Long HTTP Response Time

Para o exemplo de captura de dump após a execução de uma requisição HTTP longa, crie um código com um thread sleep de 30 segundos. Esse tempo de irá será utilizado para simular qualquer possível operação que onere o tempo de execução, como uma consulta no banco de dados, acesso a algum recurso distribuído na rede, escrita em disco ou um simples processamento complexo. O código é simples e é demonstrado a seguir.

protected void LongHttpResponseTimeButton_Click(object sender, EventArgs e) {

    System.Threading.Thread.Sleep(30000);
}

Antes de darmos início ao processo de configuração do Debug Diag, é preciso que a feature de ‘Tracing’ do IIS esteja instalada no servidor web.

Para coleta de dumps a partir de uma regra de performance, selecione o tipo de regra ‘Performance’ e clique em ‘Next’.

Selecione agora a opção ‘HTTP Response Times’, assim a regra irá basear-se no tempo de resposta das requisições HTTP.

Na tela de configuração a seguir, forneça a url relativa ou o nome da página que será analisada (essa funcionalidade também funciona para serviços WCF que utilizam o protocolo HTTP), além do tempo máximo para geração do dump de memória. No exemplo a seguir, configurei coletas na página ‘Default.aspx’ e tempo máximo de espera de 15 segundos. Clique em Ok.

A janela a seguir irá apresentar todas as urls monitoradas pela regra. Clique em ‘Next’.

Na próxima janela é preciso adicionar um ‘Dump Target’. Clique em ‘Add Dump Target’ e no campo ‘Target Type’ selecione ‘Web Application Pool’. Selecione o application pool de sua aplicação e clique em ‘Ok’.

Na próxima janela configure a regra para:

1 – Generate a UserDumo every 3 seconds

2 – Start the timer when writing the dump file completes

3 – Stop after generating 3 UserDumps

4 – Collect Full UserDumps

Cliquem em ‘Next’, atribua um nome para a regra criada e um diretório de destino para os dumps de memória. Após clicar em ‘Next’, marque a opção ‘Activate the rule now’ e clique em ‘Finish’.

Volte a aplicação e simule a lentidão para coleta dos user dumps.

Fonte: https://ferhenriquef.com/2014/12/28/captura-de-dumps-de-memria-com-o-debug-diag/#more-1812

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Post Navigation