Tendo alguns problemas de desempenho com uma imagem de VM (não tenho acesso ao host da VM, apenas ao sistema operacional convidado).
Tentando determinar por que há períodos que variam de 10 a 60 segundos em que o servidor simplesmente para de enviar quaisquer solicitações.
Ao fazer isso tenho vários contadores de desempenho funcionando, mas notei algo muito estranho, logo após esses períodos "mortos" começarem todos os meus contadores de aplicações ASP.NET (Sessões Ativas, Contagem de Instâncias de Pipeline, Solicitações em Execução) caem para zero e depois disparam voltar ao nível normal assim que escaparmos do período "morto". Veja o gráfico aqui:
Tenho 100% de certeza de que essas sessões, embora tenham caído das estatísticas do contador, ainda estavam funcionando durante todo o período.
Alguém já viu esse comportamento nos contadores antes? É possível que algum tipo de falta de recursos da VM esteja fazendo com que esses contadores se comportem mal e, possivelmente, os períodos mortos em geral?
Responder1
Acabamos de ter esse problema - estava me deixando maluco e causando muitos outros problemas. Durante esse ponto baixo, as solicitações parariam BeginRequestou MapRequestHandler, de repente, começariam a progredir através dos estados novamente, mais de 10 segundos depois.
A causa raiz foi que o aplicativo IIS estava gravando um arquivo dentro de seu próprio diretório /bin. O IIS detectou-o e emitiu uma reciclagem suave, reduzindo temporariamente o número de trabalhadores ouvintes para 0 (mostrado por Pipeline Instance Counte o motivo pelo qual encontrei esta pergunta). Isto, no entanto, não apareceu como novos processos ou algo semelhante em qualquer outra ferramenta.
Descobrimos isso fazendo um minidespejo de todos os processos do IIS usandoDebugDiag2do MS durante uma das lentidão, encontrada ao executar ping em um pequeno endpoint com o violinista. DebugDiag possui um relatório CrashHangAnalysis. Havia muitas informações naquele relatório - demorou um pouco para encontrar o HttpRuntime Shutdown Reportstacktrace incluindo System.Web.DirectoryMonitor.FireNotificationse System.Web.Compilation.BuildManager.OnWebHashFileChange.
Isso me levou a procurar no diretório prod bin e descobrir que um log de e-mail incorreto 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 no New Relic apenas mostrava o que parecia ser um vazamento constante de memória, mas na verdade todo o aplicativo estava reiniciando (mais ou menos) e apenas aumentando a memória existente. Não parecia uma reciclagem normal e os PIDs permaneceram os mesmos. Não faço ideia da mágica que o IIS estava tentando fazer.
Além disso, alterar a configuração avançada do AppPool do IIS Disable Recycling for Configuration Changespara Truenão evitou esse problema, conforme sugerido emessa outra pergunta. Tivemos que alterar e reimplantar binários para consertar.