Os contadores de desempenho do ASP.NET caem temporariamente para zero

Question

Tendo alguns problemas de desempenho com uma imagem da VM (não tenho acesso ao host da VM, apenas ao sistema operacional convidado).

Tentando determinar por que há períodos de tempo variando de 10 a 60 segundos em que o servidor apenas interrompe qualquer solicitação.

Ao fazer isso, tenho vários contadores de desempenho funcionando, mas notei algo muito estranho, logo após esses períodos "inativos" começarem todos os Contadores de Aplicativos ASP.NET (Sessões Ativas, Contagem de Instâncias de Pipeline, Solicitações em Execução) caem para zero e depois atire de volta ao nível normal quando escaparmos do período "morto". Veja gráfico aqui:

Eu tenho 100% de certeza de que essas sessões, mesmo que tenham caído da estatística do contador, ainda estavam funcionando durante todo o período de tempo.

Alguém já viu esse comportamento nos contadores antes? É possível que algum tipo de fome de recursos de VMs esteja causando esses comportamentos incorretos e, possivelmente, os períodos mortos em geral?

    

Answer 1

Acabamos de ter esse problema - estava me enlouquecendo e causando muitos outros problemas. Durante esse ponto baixo, os pedidos estariam em BeginRequest ou MapRequestHandler - então, todos eles de repente começariam a progredir nos estados novamente, mais de 10 segundos depois.

A causa raiz acabou sendo que o aplicativo IIS estava escrevendo um arquivo dentro de seu próprio diretório / bin. O IIS detectou e emitiu uma reciclagem simples, reduzindo temporariamente o número de atendentes para 0 (mostrado por Pipeline Instance Count e a razão pela qual eu encontrei essa pergunta). Isso, no entanto, não apareceu como novos processos ou algo semelhante em qualquer outra ferramenta.

Encontramos um minidump de todos os processos do IIS usando DebugDiag2 do MS durante uma das lentidões, encontrado pelo ping de um endpoint pequeno com violinista. DebugDiag tem um relatório CrashHangAnalysis. Havia muita informação nesse relatório - demorou um pouco para encontrar o HttpRuntime Shutdown Report com um stacktrace incluindo System.Web.DirectoryMonitor.FireNotifications e System.Web.Compilation.BuildManager.OnWebHashFileChange .

Isso me levou a procurar no diretório prod bin e descobrir que um log de e-mail errante estava sendo gravado lá, fazendo com que o IIS reciclasse o aplicativo. Isso foi especialmente estranho porque o gráfico de memória do aplicativo em New Relic mostrou apenas o que parecia ser um vazamento constante de memória, mas na verdade todo o aplicativo estava reiniciando (apenas) e apenas aumentando a memória existente. Não parecia uma reciclagem normal e os PIDs permaneciam iguais. Não faço ideia do que a mágica do IIS estava tentando fazer.

Além disso, alterar a configuração avançada do AppPool do IIS Disable Recycling for Configuration Changes para True não impediu esse problema, conforme sugerido em esta outra questão . Tivemos que alterar e reimplantar os binários para corrigi-lo.