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.