Capturar despejos de memória na plataforma Serviço de Aplicativo do Azure

Este artigo fornece diretrizes sobre a Microsoft Serviço de Aplicativo do Azure recursos de depuração para capturar despejos de memória. O método de captura que você usa é ditado pelo cenário em que você captura um despejo de memória para solucionar problemas de desempenho ou disponibilidade. Por exemplo, capturar um despejo de memória é diferente para um processo que está experimentando consumo excessivo de memória do que para um processo que está gerando exceções ou respondendo lentamente. O processo nesse contexto é o processo de trabalho dos Serviços de Informações da Internet (W3WP), que é executado como w3wp.exe).

Mapear cenários de despejo de memória para Serviço de Aplicativo do Azure recursos de depuração

A tabela a seguir fornece recomendações sobre os comandos que cada recurso Serviço de Aplicativo é executado para gerar um despejo de memória. Há tantas abordagens para capturar um despejo de memória que o processo pode ser confuso. Se você já estiver proficiente em capturar um despejo de memória W3WP, essas informações não se destinam a alterar sua abordagem. Em vez disso, esperamos fornecer diretrizes para usuários inexperientes que ainda não desenvolveram uma preferência.

Cenário	Serviço de Aplicativo do Azure recurso de depuração	Comando
Sem resposta ou lento	Recuperação automática (duração da solicitação)	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>
Falha (término do processo)	Monitoramento de falhas	Usa dbgHost para capturar um despejo de memória
Falha (exceções tratadas)	Rastreamentos no Application Insights/Log Analytics	Nenhum
Falha (exceções sem tratamento)	Depurador de instantâneos do Application Insights	Nenhum
Uso excessivo de CPU	Monitoramento proativo da CPU	procdump -accepteula -dc "Message" -ma <PID> <PATH>
Consumo excessivo de memória	Cura automática (limite de memória)	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>

Observação

Temos uma recomendação secundária para capturar um despejo de memória de processo W3WP no cenário sem resposta ou lento. Se esse cenário for reproduzível e você quiser capturar o despejo imediatamente, você poderá usar a ferramenta de diagnóstico Coletar um despejo de memória . Essa ferramenta está localizada na página Diagnosticar e resolver problemas de conjunto de ferramentas para o aplicativo Web Serviço de Aplicativo determinado no portal do Azure. Outro local a ser marcar para exceções gerais e baixo desempenho está na página Logs de Eventos do Aplicativo. (Você pode acessar logs de aplicativo também na página Diagnosticar e resolver problemas.) Discutimos todos os métodos disponíveis na seção "Descrições de recursos de depuração de Serviço de Aplicativo do Azure expandidas".

Descrições expandidas do cenário de processo

Esta seção contém descrições detalhadas dos seis cenários mostrados na tabela anterior.

Cenário sem resposta ou lento

Quando uma solicitação é feita em um servidor Web, algum código geralmente deve ser executado. A execução do código ocorre no processo dew3wp.exe em threads. Cada thread tem uma pilha que mostra o que está em execução no momento.

Um cenário sem resposta pode ser permanente (e provavelmente com tempo limite) ou lento. Portanto, o cenário sem resposta é aquele em que uma solicitação leva mais tempo do que o esperado para ser executada. O que você pode considerar ser lento depende do que o código está fazendo. Para algumas pessoas, um atraso de três segundos é lento. Para outros, um atraso de 15 segundos é aceitável. Basicamente, se você vir métricas de desempenho que indicam lentidão ou um super usuário afirmar que o servidor está respondendo mais devagar do que o normal, você terá um cenário sem resposta ou lento.

Cenário de falha (término do processo)

Ao longo de muitos anos, a Microsoft .NET Framework melhorou o tratamento de exceções. Na versão atual do .NET, a experiência de tratamento de exceção é ainda melhor.

Historicamente, se um desenvolvedor não colocou snippets de código em um bloco try-catch e uma exceção foi lançada, o processo foi encerrado. Nesse caso, uma exceção sem tratamento no código do desenvolvedor encerrou o processo. Versões mais modernas do .NET manipulam algumas dessas exceções "sem tratamento" para que o processo que está executando o código não falhe. No entanto, nem todas as exceções não tratadas são lançadas diretamente do código personalizado. Por exemplo, violações de acesso (como 0xC0000005 e 0x80070005) ou um estouro de pilha podem encerrar o processo.

Cenário de falha (exceções tratadas)

Embora um desenvolvedor de software tenha um cuidado especial para determinar todos os cenários possíveis sob os quais o código é executado, algo inesperado pode ocorrer. Os seguintes erros podem disparar uma exceção:

• Valores nulos inesperados
• Fundição inválida
• Um objeto instanciado ausente

É uma prática recomendada colocar a execução de código em blocos de código de captura de tentativa. Se um desenvolvedor usar esses blocos, o código terá a oportunidade de falhar normalmente gerenciando especificamente o que se segue ao evento inesperado. Uma exceção tratada é uma exceção que é lançada dentro de um bloco de tentativa e é capturada no bloco de captura correspondente. Nesse caso, o desenvolvedor antecipou que uma exceção poderia ocorrer e codificava um bloco de captura de tentativa apropriado em torno dessa seção de código.

No bloco de captura, é útil capturar informações suficientes em uma fonte de log para que o problema possa ser reproduzido e, em última instância, resolvido. Exceções são caminhos de código caros em termos de desempenho. Portanto, ter muitas exceções afeta o desempenho.

Cenário crash (exceções não tratadas)

Exceções não tratadas ocorrem quando o código tenta tomar uma ação que não espera encontrar. Como no cenário Crash (término do processo), esse código não está contido em um bloco de código try-catch. Nesse caso, o desenvolvedor não previu que uma exceção poderia ocorrer nessa seção de código.

Esse cenário difere dos dois cenários de exceção anteriores. No cenário Crash (exceções não tratadas), o código em questão é o código que o desenvolvedor escreveu. Não é o código-estrutura que está gerando a exceção, e não é uma das exceções sem tratamento que mata o processo dew3wp.exe . Além disso, como o código que está gerando uma exceção não está dentro de um bloco try-catch, não há oportunidade de lidar com a exceção graciosamente. A solução de problemas do código é inicialmente um pouco mais complexa. Seu objetivo seria encontrar o texto, o tipo e a pilha de exceção que identifica o método que está lançando essa exceção sem tratamento. Essas informações permitem identificar onde você precisa adicionar o bloco de código try-catch. Em seguida, o desenvolvedor pode adicionar a lógica semelhante aos detalhes de exceção de log que devem existir no cenário Crash (exceções não tratadas).

Cenário de uso excessivo da CPU

O que é uso excessivo de CPU? Essa situação depende do que o código faz. Em geral, se o uso da CPU do processo dew3wp.exe for de 80%, seu aplicativo estará em uma situação crítica que pode causar vários sintomas. Alguns sintomas possíveis são:

• Lentidão
• Erros
• Outro comportamento indefinido

Mesmo um uso de CPU de 20% pode ser considerado excessivo se o site estiver apenas fornecendo arquivos HTML estáticos. A solução de problemas pós-morte de um pico excessivo de CPU gerando um despejo de memória provavelmente não ajudará você a determinar o método específico que o está usando. O melhor que você pode fazer é determinar quais solicitações provavelmente demoraram mais tempo e, em seguida, tentar reproduzir o problema testando o método identificado. Esse procedimento pressupõe que você não execute monitores de desempenho nos sistemas de desempenho que capturaram essa explosão. Em muitos casos, você pode causar problemas de desempenho tendo monitores constantemente executados em tempo real.

Cenário de consumo excessivo de memória

Se um aplicativo estiver em execução em um processo de 32 bits, o consumo excessivo de memória poderá ser um problema. Mesmo uma pequena quantidade de atividade pode consumir de 2 a 3 GB de espaço de endereço virtual alocado. Um processo de 32 bits nunca pode exceder um total de 4 GB, independentemente da quantidade de memória física disponível.

Um processo de 64 bits é alocado mais memória do que um processo de 32 bits. É mais provável que o processo de 64 bits consuma a quantidade de memória física no servidor do que o processo consumirá seu espaço de endereço virtual alocado.

Portanto, o que constitui um problema excessivo de consumo de memória depende dos seguintes fatores:

• Bitness do processo (32 bits ou 64 bits)
• A quantidade de uso de memória considerada "normal".

Se o processo estiver consumindo mais memória do que o esperado, colete um despejo de memória para análise para determinar o que está consumindo recursos de memória. Para obter mais informações, consulte Criar um despejo de memória do seu Serviço de Aplicativo quando consumir muita memória.

Agora que você tem um pouco mais de contexto sobre os diferentes cenários de processo que um despejo de memória pode ajudá-lo a solucionar problemas, discutiremos a ferramenta recomendada para capturar despejos de memória na plataforma Serviço de Aplicativo do Azure.

Descrições de recursos de depuração de Serviço de Aplicativo do Azure expandidas

Na tabela na seção "Mapeamento de cenários de despejo de memória para Serviço de Aplicativo do Azure recursos de depuração", identificamos seis recursos de depuração direcionados à coleta de despejos de memória. Cada um desses recursos está acessível de dentro do portal do Azure na página Diagnosticar e resolver problemas ao selecionar o bloco Ferramentas de Diagnóstico.

Nas seções a seguir, discutimos cada um desses recursos de depuração com mais detalhes.

Recurso de recuperação automática (duração da solicitação)

O recurso de recuperação automática (duração da solicitação) é útil para capturar um despejo de memória se a resposta estiver demorando mais do que o esperado para ser concluída. Você pode ver o link para Curar Automaticamente no bloco Ferramentas de Diagnóstico na captura de tela anterior. Selecione esse link para ir diretamente ao recurso ou selecione o bloco Ferramentas de Diagnóstico para examinar todas as ferramentas disponíveis na página Ferramentas de Diagnóstico . Para obter informações sobre como configurar esse recurso, confira os seguintes artigos:

• Recuperação automática dos Serviços de Aplicativo

• Coletar e automatizar ações de diagnóstico com Azure App Services

O recurso de recuperação automática é mostrado na captura de tela a seguir.

Outro recurso chamado "Coletar um despejo de memória" é útil nesse cenário quando o problema está ocorrendo ou reproduzível no momento. Esse recurso coleta rapidamente um despejo de memória sob demanda manual.

Coletar um recurso de despejo de memória

Para entender a configuração do recurso Coletar um despejo de memória, consulte Coletar serviços de aplicativo de despejo de memória. Essa abordagem requer intervenção manual. A captura de tela a seguir mostra a página Coletar um despejo de memória .

Para usar o recurso, selecione uma conta de armazenamento na qual armazenar o despejo de memória. Em seguida, selecione de qual instância de servidor você deseja coletar o despejo de memória. Se você tiver mais de uma instância, verifique se o problema que você está depurando está ocorrendo nessa instância. Além disso, essa configuração reinicia seu aplicativo. Observe que uma reinicialização pode não ser ideal em um aplicativo de produção que está em operação.

Recurso de Monitoramento de Falhas

O recurso monitoramento de falhas é útil para capturar um despejo de memória se uma exceção não tratada fizer com que o processo W3WP seja encerrado. A captura de tela a seguir mostra a página Monitoramento de Falhas nas Ferramentas de Diagnóstico:

Para exibir um passo a passo guiado sobre como configurar o recurso de monitoramento de falhas no Serviço de Aplicativo do Azure, consulte Monitoramento de falhas em Serviço de Aplicativo do Azure.

Rastreamentos no recurso Application Insights/Log Analytics

Uma exceção tratada é um cenário no qual o código contido em um bloco de captura de tentativa tenta tomar uma ação inesperada ou sem suporte. Por exemplo, o snippet de código a seguir tenta dividir um número por zero, embora esta seja uma operação ilegal:

decimal percentage = 0, number = 1000, total = 0;
try
{
  percentage = number / total;
}
catch (DivideByZeroException divEx)
{
  _logger.LogError("A handled exception just happened: -> {divEx.Message}", divEx.Message);
}

Esse snippet de código causa uma exceção divide-por-zero que é tratada porque a operação matemática sem suporte é colocada dentro de um bloco de captura de tentativa. O Application Insights não faz log com exceções tratadas, a menos que você inclua intencionalmente o pacote NuGet Microsoft.ApplicationInsights no código do aplicativo e adicione o código para registrar as informações. Se a exceção ocorrer depois de adicionar o código, você poderá exibir a entrada no Log Analytics, conforme mostrado na captura de tela a seguir.

O seguinte código Kusto contém a consulta usada para extrair os dados do Log Analytics:

traces
| where message has "handled"
 | project timestamp, severityLevel, message, operation_Name, cloud_RoleInstance

A message coluna é o local em que você pode armazenar os detalhes necessários para encontrar a causa raiz da exceção. O código usado para gravar essa consulta está no snippet de código divisão por zero. O desenvolvedor de software que escreveu esse código é a melhor pessoa para perguntar sobre esses tipos de exceções e os atributos necessários para capturar para analisar causas raiz.

A melhor abordagem para adicionar essa funcionalidade ao código do aplicativo depende da pilha de código do aplicativo e da versão que você tem (por exemplo, ASP.NET, ASP.NET Core, MVC, Razor e assim por diante). Para determinar a melhor abordagem para seu cenário, examine o log do Application Insights com o .NET.

Recurso logs de eventos do aplicativo (exceções tratadas)

Você também pode encontrar exceções não tratadas na exceção manipulada na página Logs de Eventos de Aplicativo das Ferramentas de Diagnóstico no portal do Azure, conforme mostrado na captura de tela a seguir.

Nesta situação, você recebe a mesma mensagem de erro que você registrou em seu código. No entanto, você perde alguma flexibilidade em como pode personalizar as consultas nos logs de rastreamento do Application Insights.

Recurso Depurador de Instantâneo do Application Insights

Exceções não tratadas também são registradas na página Logs de Eventos do Aplicativo , conforme mostrado no texto de saída na próxima seção. No entanto, você também pode habilitar o Depurador de Instantâneos do Application Insights. Essa abordagem não exige que você adicione nenhum código ao seu aplicativo.

Recurso logs de eventos de aplicativo (exceções não tratadas)

A saída a seguir é da página Logs de Eventos de Aplicativo das Ferramentas de Diagnóstico no portal do Azure. Ele mostra um texto de exemplo de uma exceção de aplicativo sem tratamento:

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: 311d8cb5d10b1a6e
TraceId: 041929768411c12f1c3f1ccbc91f6751
ParentId: 0000000000000000
RequestId: 8000006d-0001-bf00-b63f-84710c7967bb
RequestPath: /Unhandled

An unhandled exception has occurred while executing the request.

Exception:
System.DivideByZeroException: Attempted to divide by zero.
   at System.Decimal.DecCalc.VarDecDiv(DecCalc& d1, DecCalc& d2)
   at System.Decimal.op_Division(Decimal d1, Decimal d2)
   at contosotest.Pages.Pages Unhandled.ExecuteAsync()
     in C:\Users\contoso\source\repos\contosorepo\contosorepo\Pages\Unhandled.cshtml:line 12

Uma diferença aqui da exceção tratada no log de aplicativos é a existência da pilha que identifica o método e a linha da qual a exceção é gerada. Além disso, você pode assumir com segurança que a funcionalidade Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware contém código para capturar essa exceção sem tratamento para que o término do processo seja evitado. A exceção é mostrada no Application Insights na guia Exceções da página Falhas , conforme mostrado na captura de tela a seguir.

Nesta exibição, você verá todas as Exceções, não apenas a que você está procurando. A representação gráfica de todas as exceções que ocorrem em seu aplicativo é útil para obter uma visão geral da integridade do sistema. O dashboard do Application Insights é mais útil visualmente em comparação com os logs de eventos do aplicativo.

Recurso de monitoramento de CPU proativo

Durante cenários excessivos de uso da CPU, você pode usar a ferramenta de monitoramento de CPU proativa. Para obter informações sobre essa ferramenta, consulte Atenuar seus problemas de CPU antes que eles aconteçam. A imagem a seguir mostra a página Monitoramento proativo da CPU em Ferramentas de Diagnóstico.

Você deve considerar o uso da CPU de 80% ou mais como uma situação crítica que requer investigação imediata. Na página Monitoramento proativo da CPU , você pode definir o cenário para o qual deseja capturar um despejo de memória com base nas seguintes categorias de monitoramento de dados:

• Limite da CPU
• Limite segundos
• Monitorar frequência

O Limite da CPU identifica a quantidade de CPU do computador que o processo direcionado usa (W3WP nesse caso). Threshold Seconds é a quantidade de tempo que a CPU foi usada no limite da CPU. Por exemplo, se houver 75% de uso de CPU por um total de 30 segundos, o despejo de memória será capturado. Conforme configurado na página Monitoramento Proativo da CPU , o processo seria verificado se há violações de limite a cada 15 segundos.

Recurso de recuperação automática (limite de memória)

O recurso de recuperação automática (limite de memória) é útil para capturar um despejo de memória se o processo estiver consumindo mais memória do que o esperado. Novamente, preste atenção à bit (32 ou 64). Se você sofrer pressão de memória no contexto do processo de 32 bits e o consumo de memória for esperado, você poderá considerar a alteração da bit para 64. Normalmente, se você alterar a bit, também precisará recompilar o aplicativo.

Alterar a bit não reduz a quantidade de memória usada. Ele permite que o processo use mais de 4 GB de memória total. No entanto, se o consumo de memória não for como esperado, você poderá usar esse recurso para determinar o que está consumindo a memória. Em seguida, você pode tomar uma ação para controlar o consumo de memória.

Na seção "Descrições de recursos de depuração de Serviço de Aplicativo do Azure expandidas", você pode ver o link para Curar Automaticamente no bloco Ferramentas de Diagnóstico na primeira captura de tela. Selecione esse link para ir diretamente ao recurso ou selecione o bloco e examine todas as ferramentas disponíveis na página Ferramentas de Diagnóstico . Para obter mais informações, acesse a seção "Cura automática" de Serviço de Aplicativo do Azure diagnóstico visão geral.

O recurso de recuperação automática é mostrado na captura de tela a seguir.

Ao selecionar o bloco Limite de Memória , você terá a opção de inserir um valor de memória que dispara a captura de um despejo de memória quando esse limite de memória é violado. Por exemplo, se você inserir 6291456 como o valor, um despejo de memória do processo W3WP será feito quando 6 GB de memória são consumidos.

O recurso Coletar um despejo de memória será útil nesse cenário se o problema estiver ocorrendo ou reproduzido no momento. Esse recurso coleta rapidamente um despejo de memória sob demanda manual. Para obter mais informações, consulte a seção "Coletar um despejo de memória ".

Descrições de comando expandidas

A arte da coleção de despejo de memória leva algum tempo para estudar, experimentar e aperfeiçoar. Conforme você aprendeu, diferentes procedimentos são baseados nos sintomas que o processo está mostrando, conforme listado na tabela na seção "Descrições de cenário de processo expandido ". Por outro lado, a tabela a seguir compara o comando de captura de despejo de memória do Serviço de Aplicativo do Azure com o comando procdump que você executa manualmente no console do Kudu.

Cenário	comando Serviço de Aplicativo do Azure	Comando procdump geral
Sem resposta ou lento	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>	procdump -accepteula -ma -n 3 -s # <PID>
Falha (término do processo)	Usa o DbgHost para capturar o despejo de memória	procdump -accepteula -ma -t <PID>
Falha (exceções tratadas)	Nenhum (Application Insights)	procdump -accepteula -ma -e 1 -f <filter> <PID>
Falha (exceções sem tratamento)	Nenhum (Depurador de Instantâneos do Application Insights)	procdump -accepteula -ma -e <PID>
Uso excessivo de CPU	procdump -accepteula -dc "Message" -ma <PID> <PATH>	procdump -accepteula -ma -n 3 -s # -c 80 <PID>
Consumo excessivo de memória	procdump -accepteula -r -dc "Message" -ma <PID> <PATH>	procdump -accepteula -ma -m 2000 <PID>

Os comandos que você usa nos recursos de captura de despejo de memória em Serviço de Aplicativo do Azure diferem dos comandos de procdump que você usaria se capturasse despejos manualmente. Se você revisar a seção anterior, deverá observar que o recurso do portal de coleta de despejo de memória no Serviço de Aplicativo do Azure expõe a configuração. Por exemplo, no cenário de consumo excessivo de memória na tabela, o comando executado pela plataforma não contém um limite de memória. No entanto, o comando mostrado na coluna de comandos procdump geral especifica um limite de memória.

Uma ferramenta chamada DaaS (Diagnóstico como serviço) é responsável por gerenciar e monitorar a configuração especificada no portal de depuração Serviço de Aplicativo do Azure. Essa ferramenta é executada como um trabalho Web nas VMs (máquinas virtuais) que executam seu aplicativo Web. Um benefício dessa ferramenta é que você pode direcionar uma VM específica em seu farm web. Se você tentar capturar um despejo de memória usando o procdump diretamente, pode ser desafiador identificar, direcionar, acessar e executar esse comando em uma instância específica. Para obter mais informações sobre o DaaS, consulte DaaS – Diagnóstico como um serviço para sites do Azure.

O uso excessivo da CPU é outro motivo pelo qual a plataforma gerencia a coleção de despejo de memória para que ela corresponda aos padrões de procdump recomendados. O comando procdump, conforme mostrado na tabela anterior, coleta três (-n 3) despejos de memória completos (-ma) com 30 segundos de diferença (-s #em que # é 30) quando o uso da CPU é maior ou igual a 80% (-c 80). Por fim, você fornece a ID do processo (<PID>) para o comando: procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Você pode ver a configuração do portal na seção "Monitoramento proativo da CPU ". Para brevidade, essa seção mostrou apenas as três primeiras opções de configuração: Limite de CPU (-c), Segundos de Limite (-s) e Frequência de Monitor. A captura de tela a seguir ilustra que Configurar Ação, Ações Máximas (-n) e Duração Máxima são recursos extras disponíveis.

Depois de estudar as diferentes abordagens para capturar despejos de memória, a próxima etapa é praticar a criação de capturas. Você pode usar exemplos de código no GitHub em conjunto com laboratórios de depuração do IIS e Azure Functions para simular cada um dos cenários listados nas duas tabelas. Depois de implantar o código na plataforma Serviço de Aplicativo do Azure, você pode usar essas ferramentas para capturar o despejo de memória em cada cenário fornecido. Ao longo do tempo e após a prática, você pode aperfeiçoar sua abordagem para capturar despejos de memória usando os recursos de depuração Serviço de Aplicativo do Azure. A lista a seguir contém algumas sugestões a serem consideradas à medida que você continua a aprender sobre a coleção de despejo de memória:

• A captura de um despejo de memória consome recursos significativos do sistema e interrompe ainda mais o desempenho.

• Capturar despejos de memória na primeira chance não é ideal porque você provavelmente capturará muitos. Esses despejos de memória de primeira chance provavelmente são irrelevantes.

• Recomendamos desabilitar o Application Insights antes de capturar um despejo de memória W3WP.

Depois que o despejo de memória é coletado, a próxima etapa é analisar o despejo de memória para determinar a causa do problema e corrigir esse problema.

Próximas etapas (analisando o despejo de memória)

Discutir como analisar despejos de memória está fora do escopo deste artigo. No entanto, há muitos recursos para esse assunto, como a série de treinamento Ferramentas de Defrag e uma lista de comandos WinDbg obrigatórios.

Você deve ter notado a opção Configurar Ação na captura de tela anterior. A configuração padrão para essa opção é CollectAndKill. Essa configuração significa que o processo é morto após o despejo de memória ser coletado. Uma configuração chamada CollectKillAndAnalyze analisa o despejo de memória coletado. Nesse cenário, a análise da plataforma pode encontrar o problema para que você não precise abrir o despejo de memória no WinDbg e analisá-lo.

Há outras opções para solucionar problemas de desempenho e solução de problemas de desempenho na plataforma Serviço de Aplicativo do Azure. Este artigo se concentra na coleção de despejo de memória e faz algumas recomendações para abordar o diagnóstico usando esses métodos. Se você já estudou, experimentou e aperfeiçoou seus procedimentos de coleção e eles funcionam bem para você, você deve continuar a usar esses procedimentos.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.