Capturar capturas de memória na plataforma do Serviço de Aplicações do Azure

Este artigo fornece orientações sobre as funcionalidades de depuração do Serviço de Aplicações do Microsoft Azure para capturar capturas de memória. O método de captura que utiliza é ditado pelo cenário em que captura uma captura de memória para resolver um problema de desempenho ou disponibilidade. Por exemplo, capturar uma captura de memória é diferente para um processo que está a sofrer um consumo excessivo de memória do que para um processo que está a gerar exceções ou a responder lentamente. Neste contexto, o processo é o processo de trabalho dos Serviços de Informação Internet (IIS) (W3WP, que é executado como w3wp.exe).

Mapear cenários de captura de memória para funcionalidades de depuração do Serviço de Aplicações do Azure

A tabela seguinte fornece recomendações sobre os comandos que cada funcionalidade do Serviço de Aplicações executa para gerar uma captura de memória. Existem tantas abordagens para capturar uma captura de memória que o processo pode ser confuso. Se já for proficiente na captura de uma captura de memória W3WP, estas informações não se destinam a alterar a sua abordagem. Em vez disso, esperamos fornecer orientações para utilizadores inexperientes que ainda não desenvolveram uma preferência.

Descrições de cenários de processo expandidos

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

Cenário sem resposta ou lento

Quando é efetuado um pedido a um servidor Web, é normalmente necessário executar algum código. A execução do código ocorre no processo dew3wp.exe em threads. Cada thread tem uma pilha que mostra o que está atualmente em execução.

Um cenário sem resposta pode ser permanente (e provavelmente exceder o limite de tempo) ou lento. Por conseguinte, o cenário sem resposta é aquele em que um pedido demora mais tempo do que o esperado a ser executado. O que pode considerar ser lento depende do que o código está a fazer. Para algumas pessoas, um atraso de três segundos é lento. Para outros, é aceitável um atraso de 15 segundos. Basicamente, se vir métricas de desempenho que indicam lentidão ou um superutilizador indicar que o servidor está a responder mais lentamente do que o normal, significa que tem um cenário sem resposta ou lento.

Cenário de falha (terminação do processo)

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

Historicamente, se um programador não colocou fragmentos de código num bloco try-catch e foi emitida uma exceção, o processo terminou. Nesse caso, uma exceção não processada no código do programador terminou o processo. As versões mais modernas do .NET processam algumas destas exceções "não processadas", para que o processo que está a executar o código não falhe. No entanto, nem todas as exceções não processadas são emitidas diretamente a partir do código personalizado. Por exemplo, as violações de acesso (como 0xC0000005 e 0x80070005) ou uma capacidade excedida da pilha podem terminar o processo.

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

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

• Valores nulos inesperados
• Conversão de tipo cast invá
• Um objeto instanciado em falta

É uma melhor prática colocar a execução de código em blocos de código try-catch. Se um programador utilizar estes blocos, o código tem a oportunidade de falhar corretamente ao gerir especificamente o que se segue ao evento inesperado. Uma exceção processada é uma exceção que é emitida dentro de um bloco de tentativa e é capturada no bloco de captura correspondente. Neste caso, o programador antecipou que poderia ocorrer uma exceção e codificava um bloco try-catch adequado em torno dessa secção de código.

No bloco catch, é útil capturar informações suficientes numa origem de registo para que o problema possa ser reproduzido e, em última análise, resolvido. As exceções são caminhos de código dispendiosos em termos de desempenho. Por conseguinte, ter muitas exceções afeta o desempenho.

Cenário de falha (exceções não processadas)

As exceções não processadas ocorrem quando o código tenta efetuar uma ação que não espera encontrar. Tal como no cenário Falha (terminação do processo ), esse código não está contido num bloco de código try-catch. Neste caso, o programador não antecipou que poderia ocorrer uma exceção nessa secção de código.

Este cenário difere dos dois cenários de exceção anteriores. No cenário Falha (exceções não processadas), o código em questão é o código que o programador escreveu. Não é o código de estrutura que está a gerar a exceção e não é uma das exceções não processadas que elimina o processo dew3wp.exe . Além disso, como o código que está a gerar uma exceção não está dentro de um bloco try-catch, não há nenhuma oportunidade de lidar com a exceção corretamente. A resolução de problemas do código é inicialmente um pouco mais complexa. O seu objetivo seria localizar o texto, o tipo e a pilha de exceção que identificam o método que está a gerar esta exceção não processada. Essas informações permitem-lhe identificar onde tem de adicionar o bloco de código try-catch. Em seguida, o programador pode adicionar a lógica semelhante para registar os detalhes da exceção que devem existir no cenário Falha (exceções não processadas ).

Cenário de utilização excessiva da CPU

O que é a utilização excessiva da CPU? Esta situação depende do que o código faz. Em geral, se a utilização da CPU do processo dew3wp.exe for de 80%, a aplicação encontra-se numa situação crítica que pode causar vários sintomas. Alguns sintomas possíveis são:

• Lentidão
• Erros
• Outro comportamento indefinido

Mesmo uma utilização de CPU de 20 por cento pode ser considerada excessiva se o site estiver apenas a fornecer ficheiros HTML estáticos. A resolução de problemas pós-morte de um pico de CPU excessivo ao gerar uma captura de memória provavelmente não o ajudará a determinar o método específico que está a utilizá-lo. O melhor que pode fazer é determinar quais os pedidos que provavelmente demoraram mais tempo e, em seguida, tentar reproduzir o problema ao testar o método identificado. Este procedimento pressupõe que não executa monitores de desempenho nos sistemas de desempenho que capturaram essa explosão. Em muitos casos, pode causar problemas de desempenho ao executar monitores constantemente em tempo real.

Cenário de consumo excessivo de memória

Se uma aplicação estiver em execução num processo de 32 bits, o consumo excessivo de memória pode ser um problema. Mesmo uma pequena quantidade de atividade pode consumir os 2 a 3 GB do espaço de endereços 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.

É atribuído mais memória a um processo de 64 bits do que a 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á o espaço de endereços virtual alocado.

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

• Bitness do processo (32 bits ou 64 bits)
• A quantidade de utilização da memória considerada "normal".

Se o processo estiver a consumir mais memória do que o esperado, recolha uma captura de memória para análise para determinar o que está a consumir recursos de memória. Para obter mais informações, veja Create a memory dump of your App Service when it consumes too much memory (Criar uma captura de memória do Serviço de Aplicações quando consome demasiada memória).

Agora que tem um pouco mais de contexto sobre os diferentes cenários de processo que uma captura de memória pode ajudar a resolver, vamos abordar a ferramenta recomendada para capturar capturas de memória na plataforma do Serviço de Aplicações do Azure.

Descrições de funcionalidades de depuração expandidas do Serviço de Aplicações do Azure

Na tabela na secção "Mapping memory dump scenarios to Azure App Service debugging features" (Mapear cenários de captura de memória para funcionalidades de depuração do Serviço de Aplicações do Azure ), identificámos seis funcionalidades de depuração direcionadas para a recolha de capturas de memória. Cada uma destas funcionalidades está acessível a partir do portal do Azure na página Diagnosticar e resolver problemas quando seleciona o mosaico Ferramentas de Diagnóstico .

Nas secções seguintes, vamos abordar cada uma destas funcionalidades de depuração mais detalhadamente.

Funcionalidade de recuperação automática (duração do pedido)

A funcionalidade de recuperação automática (duração do pedido) é útil para capturar uma captura de memória se a resposta estiver a demorar mais tempo do que o esperado para ser concluída. Pode ver a ligação para a Recuperação Automática no mosaico Ferramentas de Diagnóstico na captura de ecrã anterior. Selecione essa ligação para aceder diretamente à funcionalidade ou selecione o mosaico Ferramentas de Diagnóstico para rever todas as ferramentas disponíveis na página Ferramentas de Diagnóstico . Para obter informações sobre como configurar esta funcionalidade, veja os seguintes artigos:

• Recuperação automática dos Serviços Aplicacionais

• Recolher e automatizar ações de diagnóstico com os Serviços de Aplicações do Azure

A funcionalidade de recuperação automática é apresentada na captura de ecrã seguinte.

Outra funcionalidade denominada "Recolher uma captura de memória" é útil neste cenário quando o problema está a ocorrer ou é reproduzível. Esta funcionalidade recolhe rapidamente uma captura de memória a pedido manual.

Recolher uma funcionalidade de captura de memória

Para compreender a configuração da funcionalidade Recolher uma captura de memória, veja Recolher serviços de aplicações de captura de memória. Esta abordagem requer intervenção manual. A captura de ecrã seguinte mostra a página Recolher uma captura de memória .

Para utilizar a funcionalidade, selecione uma conta de armazenamento na qual pretende armazenar a captura de memória. Em seguida, selecione a instância do servidor a partir da qual pretende recolher a captura de memória. Se tiver mais do que uma única instância, confirme que o problema que está a depurar está a ocorrer nessa instância. Repare que um reinício pode não ser ideal numa aplicação de produção em funcionamento.

Funcionalidade monitorização de falhas

A funcionalidade Monitorização de Falhas é útil para capturar uma captura de memória se uma exceção não processada fizer com que o processo W3WP termine. A seguinte captura de ecrã mostra a página Monitorização de Falhas nas Ferramentas de Diagnóstico:

Para ver instruções guiadas sobre como configurar a funcionalidade de monitorização de falhas no Serviço de Aplicações do Azure, veja Monitorização de falhas no Serviço de Aplicações do Azure.

Rastreios na funcionalidade Application Insights/Log Analytics

Uma exceção processada é um cenário em que o código contido num bloco try-catch tenta efetuar uma ação inesperada ou não suportada. Por exemplo, o fragmento de código seguinte 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);
}

Este fragmento de código causa uma exceção de divisão por zero que é processada porque a operação matemática não suportada é colocada num bloco try-catch. O Application Insights não regista exceções processadas, a menos que inclua intencionalmente o pacote NuGet Microsoft.ApplicationInsights no código da aplicação e, em seguida, adicione o código para registar as informações. Se a exceção ocorrer depois de adicionar o código, pode ver a entrada no Log Analytics, conforme mostrado na captura de ecrã seguinte.

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

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

A message coluna é a localização na qual pode armazenar os detalhes necessários para encontrar a causa da exceção. O código utilizado para escrever esta consulta está no fragmento de código divisão por zero. O programador de software que escreveu este código é a melhor pessoa para perguntar sobre estes tipos de exceções e os atributos que são necessários para capturar para analisar as causas raiz.

A melhor abordagem para adicionar esta funcionalidade ao código da aplicação depende da pilha de código da aplicação e da versão que tem (por exemplo, ASP.NET, ASP.NET Core, MVC, Razor, etc.). Para determinar a melhor abordagem para o seu cenário, veja Registo do Application Insights com .NET.

Funcionalidade de registos de eventos da aplicação (exceções processadas)

Também pode encontrar exceções não processadas na exceção processada na página Registos de Eventos da Aplicação das Ferramentas de Diagnóstico no portal do Azure, conforme mostrado na seguinte captura de ecrã.

Nesta situação, recebe a mesma mensagem de erro que registou através do código. No entanto, perde alguma flexibilidade na forma como pode personalizar as consultas nos registos de rastreio do Application Insights.

Funcionalidade Depurador instantâneo do Application Insights

As exceções não processadas também são registadas na página Registos de Eventos da Aplicação , conforme mostrado no texto de saída na secção seguinte. No entanto, também pode ativar o Snapshot Debugger do Application Insights. Esta abordagem não requer que adicione código à sua aplicação.

Funcionalidade de registos de eventos da aplicação (exceções não processadas)

O resultado seguinte é da página Registos de Eventos da Aplicação das Ferramentas de Diagnóstico no portal do Azure. Mostra algum texto de exemplo de uma exceção de aplicação não processada:

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 processada no Registo de aplicações é a existência da pilha que identifica o método e a linha a partir da qual a exceção é emitida. Além disso, pode assumir com segurança que a funcionalidade Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware contém código para detetar esta exceção não processada para evitar a terminação do processo. A exceção é apresentada no Application Insights no separador Exceções da página Falhas , conforme mostrado na captura de ecrã seguinte.

Nesta vista, verá todas as Exceções e não apenas a que está a procurar. A representação gráfica de todas as exceções que ocorrem na sua aplicação é útil para obter uma descrição geral do estado de funcionamento do seu sistema. O dashboard do Application Insights é mais útil visualmente em comparação com os registos de eventos da Aplicação.

Funcionalidade de monitorização proativa da CPU

Durante cenários de utilização excessiva da CPU, pode utilizar a ferramenta de monitorização proativa da CPU. Para obter informações sobre esta ferramenta, veja Mitigar os problemas da CPU antes de acontecerem. A imagem seguinte mostra a página Monitorização Proativa da CPU nas Ferramentas de Diagnóstico.

Deve considerar a utilização da CPU de 80% ou mais como uma situação crítica que requer investigação imediata. Na página Monitorização Proativa da CPU , pode definir o cenário para o qual pretende capturar uma captura de memória com base nas seguintes categorias de monitorização de dados:

• Limiar da CPU
• Segundos de Limiar
• Frequência do Monitor

O Limiar da CPU identifica a quantidade de CPU do computador que o processo visado utiliza (W3WP neste caso). Threshold Seconds é a quantidade de tempo que a CPU foi utilizada no Limiar da CPU. Por exemplo, se houver 75% de utilização da CPU num total de 30 segundos, a captura de memória será capturada. Conforme configurado na página Monitorização Proativa da CPU , o processo seria verificado quanto a falhas de limiar a cada 15 segundos.

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

A funcionalidade de recuperação automática (limite de memória) é útil para capturar uma captura de memória se o processo estiver a consumir mais memória do que o esperado. Mais uma vez, preste atenção à bitness (32 ou 64). Se ocorrer pressão de memória no contexto do processo de 32 bits e se o consumo de memória for esperado, poderá considerar alterar a bitness para 64. Normalmente, se alterar a bitness, também terá de recompilar a aplicação.

Alterar a bitness não reduz a quantidade de memória utilizada. Permite que o processo utilize mais de 4 GB de memória total. No entanto, se o consumo de memória não for o esperado, pode utilizar esta funcionalidade para determinar o que está a consumir a memória. Em seguida, pode tomar uma ação para controlar o consumo de memória.

Na secção "Descrições de funcionalidades de depuração expandidas do Serviço de Aplicações do Azure ", pode ver a ligação para a Recuperação Automática no mosaico Ferramentas de Diagnóstico na primeira captura de ecrã. Selecione essa ligação para aceder diretamente à funcionalidade ou selecione o mosaico e reveja todas as ferramentas disponíveis na página Ferramentas de Diagnóstico . Para obter mais informações, aceda à secção "Recuperação automática" da descrição geral dos diagnósticos do Serviço de Aplicações do Azure.

A funcionalidade de recuperação automática é apresentada na captura de ecrã seguinte.

Quando seleciona o mosaico Limite de Memória , tem a opção de introduzir um valor de memória que aciona a captura de uma captura de memória quando esse limite de memória é violado. Por exemplo, se introduzir 6291456 como o valor, é realizada uma captura de memória do processo W3WP quando é consumida 6 GB de memória.

A funcionalidade Recolher uma Captura de Memória é útil neste cenário se o problema estiver a ocorrer ou reproduzível. Esta funcionalidade recolhe rapidamente uma captura de memória a pedido manual. Para obter mais informações, consulte a secção "Recolher uma captura de memória" .

Descrições de comandos expandidas

A coleção de arte da informação de falha de sistema da memória demora algum tempo a estudar, experimentar e aperfeiçoar. Como aprendeu, os diferentes procedimentos baseiam-se nos sintomas que o processo está a apresentar, conforme listado na tabela na secção "Descrições de cenários de processo expandido" . Por outro lado, a tabela seguinte compara o comando de captura de memória do Serviço de Aplicações do Azure com o comando procdump que executa manualmente a partir da consola do Kudu.

Os comandos que utiliza nas funcionalidades de captura de memória no Serviço de Aplicações do Azure diferem dos comandos procdump que utilizaria se capturasse as informações de falha de sistema manualmente. Se rever a secção anterior, deverá reparar que a funcionalidade do portal de recolha de informações de memória no Serviço de Aplicações do Azure expõe a configuração. Por exemplo, no cenário de consumo excessivo de memória na tabela, o comando que a plataforma executa não contém um limiar de memória. No entanto, o comando apresentado na coluna de comandos procdump geral especifica um limiar de memória.

Uma ferramenta com o nome DaaS (Diagnóstico como serviço) é responsável por gerir e monitorizar a configuração especificada no portal de depuração do Serviço de Aplicações do Azure. Esta ferramenta é executada como uma tarefa Web nas máquinas virtuais (VMs) que executam a sua aplicação Web. Uma vantagem desta ferramenta é que pode visar uma VM específica no seu web farm. Se tentar capturar uma captura de memória com o procdump diretamente, pode ser difícil identificar, direcionar, aceder e executar esse comando numa instância específica. Para obter mais informações sobre o DaaS, veja DaaS – Diagnóstico como um serviço para sites do Azure.

A utilização excessiva da CPU é outra das razões pelas quais a plataforma gere a recolha de informações de falha de sistema de memória para que correspondam aos padrões de procdump recomendados. O comando procdump, conforme mostrado na tabela anterior, recolhe três () capturas de memória completas (-n 3-ma) com 30 segundos de diferença (-s #em que # é 30) quando a utilização da CPU é maior ou igual a 80 por cento (-c 80). Por fim, forneça o ID do processo (<PID>) ao comando: procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Pode ver a configuração do portal na secção "Monitorização proativa da CPU" . Por questões de brevidade, essa secção mostrou apenas as três primeiras opções de configuração: Limiar da CPU (-c), Segundos de Limiar (-s) e Frequência do Monitor. A captura de ecrã seguinte ilustra que Configurar Ação, Ações Máximas (-n) e Duração Máxima são funcionalidades adicionais disponíveis.

Depois de estudar as diferentes abordagens para capturar capturas de memória, o próximo passo é praticar a realização de capturas. Pode utilizar exemplos de código no GitHub em conjunto com os laboratórios de depuração do IIS e as Funções do Azure para simular cada um dos cenários listados nas duas tabelas. Depois de implementar o código na plataforma do Serviço de Aplicações do Azure, pode utilizar estas ferramentas para capturar a captura de memória em cada cenário. Ao longo do tempo e após a prática, pode aperfeiçoar a sua abordagem para capturar capturas de memória com as funcionalidades de depuração do Serviço de Aplicações do Azure. A lista seguinte contém algumas sugestões a considerar à medida que continua a saber mais sobre a recolha de informações de memória:

• Capturar uma captura de memória consome recursos de sistema significativos e interrompe ainda mais o desempenho.

• Capturar capturas de memória na primeira oportunidade não é o ideal, porque provavelmente irá capturar demasiados. Essas capturas de memória de primeira oportunidade são provavelmente irrelevantes.

• Recomendamos que desative o Application Insights antes de capturar uma captura de memória W3WP.

Após a captura de memória ser recolhida, o passo seguinte é analisar a captura de memória para determinar a causa do problema e, em seguida, corrigir esse problema.

Passos seguintes (analisar a captura de memória)

Discutir como analisar capturas de memória está fora do âmbito deste artigo. No entanto, existem muitos recursos para esse assunto, como a série de preparação Ferramentas de Desfragagem e uma lista de comandos WinDbg obrigatórios.

Poderá ter reparado na opção Configurar Ação na captura de ecrã anterior. A predefinição para esta opção é CollectAndKill. Esta definição significa que o processo é terminado após a captura de memória ser recolhida. Uma definição denominada CollectKillAndAnalyze analisa a informação de falha de sistema de memória recolhida. Nesse cenário, a análise da plataforma poderá encontrar o problema para que não tenha de abrir a captura de memória no WinDbg e analisá-la.

Existem outras opções para resolver e diagnosticar problemas de desempenho na plataforma do Serviço de Aplicações do Azure. Este artigo centra-se na recolha de informação de falha de sistema da memória e faz algumas recomendações para abordar o diagnóstico através destes métodos. Se já estudou, experimentou e aperfeiçoou os seus procedimentos de recolha e funcionam bem para si, deve continuar a utilizar 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.