Tengo algunos problemas de rendimiento con una imagen de VM (no tengo acceso al host de VM, solo al sistema operativo invitado).
Intentando determinar por qué hay períodos de tiempo que oscilan entre 10 y 60 segundos en los que el servidor simplemente deja de enviar solicitudes.
Al hacer esto, tengo varios contadores de rendimiento, pero noté algo muy extraño: poco después de que comiencen estos períodos "muertos", todos mis contadores de aplicaciones ASP.NET (sesiones activas, recuento de instancias de canalización, solicitudes en ejecución) caen a cero y luego se disparan. volver al nivel normal una vez que escapemos del período "muerto". Ver gráfico aquí:
Estoy 100% seguro de que esas sesiones, aunque desaparecieron de las estadísticas del contador, siguieron funcionando durante todo el período de tiempo.
¿Alguien ha visto este comportamiento en los mostradores antes? ¿Es posible que algún tipo de escasez de recursos de VM esté causando que estos contadores se comporten mal y posiblemente los períodos muertos en general?
Respuesta1
Acabamos de tener este problema: me estaba volviendo loco y causando muchos otros problemas. Durante ese punto bajo, las solicitudes se detenían BeginRequesto MapRequestHandler, luego, de repente, todas comenzaban a progresar a través de los estados nuevamente más de 10 segundos después.
La causa principal terminó siendo que la aplicación IIS estaba escribiendo un archivo dentro de su propio directorio /bin. IIS lo detectó y emitió un reciclaje suave, reduciendo temporalmente la cantidad de trabajadores en escucha a 0 (como se muestra Pipeline Instance County la razón por la que encontré esta pregunta). Sin embargo, esto no apareció como nuevos procesos o similares en ninguna otra herramienta.
Lo encontramos haciendo un minivolcado de todos los procesos de IIS usandoDebugDiag2desde MS durante una de las desaceleraciones, que se encuentra haciendo ping a un pequeño punto final con Fiddler. DebugDiag tiene un informe CrashHangAnalysis. Había mucha información en ese informe; tomó un tiempo encontrar el HttpRuntime Shutdown Reportseguimiento de pila que incluía System.Web.DirectoryMonitor.FireNotificationsy System.Web.Compilation.BuildManager.OnWebHashFileChange.
Eso me llevó a buscar en el directorio prod bin y descubrir que allí se estaba escribiendo un registro de correo electrónico erróneo, lo que provocó que IIS reciclara la aplicación. Esto fue especialmente extraño porque el gráfico de memoria de la aplicación en New Relic solo mostraba lo que parecía ser una pérdida de memoria constante, pero en realidad toda la aplicación se estaba reiniciando (más o menos) y simplemente aumentando la memoria existente. No parecía un reciclaje normal y los PID permanecieron iguales. No tengo idea de qué magia estaba tratando de hacer IIS.
Además, cambiar la configuración avanzada de IIS AppPool Disable Recycling for Configuration Changesno Trueevitó este problema como se sugiere enesta otra pregunta. Tuvimos que cambiar y volver a implementar los archivos binarios para solucionarlo.