c# - Detección de fugas de memoria en ASP.NET
telerik iis-7.5 (5)
Mi equipo de desarrollo está utilizando ASP.NET 3.5 / 4.0 en este momento, y nuestros sitios se están ejecutando en IIS 7.5. Recientemente, hemos tenido problemas (aproximadamente una vez a la semana) que provocan que se generen excepciones de falta de memoria en nuestras aplicaciones ASP.NET. La "Solución" es reiniciar el grupo de aplicaciones en nuestro sitio web. Digo "Solución" porque difícilmente es una solución; es más un vendaje lo que hace que nuestro conjunto de aplicaciones se ejecute en un estado razonable. Me parece que algunas aplicaciones o muchas aplicaciones pierden memoria, que se acumula con el tiempo y causa la excepción de falta de memoria. Aunque puedo configurar IIS para reiniciar periódicamente el grupo de aplicaciones, prefiero saber cómo puedo detectar las pérdidas de memoria para intentar arreglar el programa en lugar de seguir aplicando curitas. ¿Hay alguna herramienta que posiblemente pueda detectar y registrar fugas de memoria para las aplicaciones ASP.NET?
Además, realmente empezamos a ver más de este problema cuando cambiamos al uso de los controles RAD de Telerik. ¿Alguien más ha tenido problemas similares a este usando estos controles?
Gracias,
Aaron
Anteriormente publiqué esta guía en respuesta a otra pregunta, pero esa pregunta y mi respuesta parecen haber sido eliminadas. No es para los débiles de corazón:
- Instale las herramientas de depuración para Windows (disponible como parte del SDK de Windows ) en el servidor
Cuando la aplicación ha estado ejecutándose por un tiempo, use adplus para capturar un volcado de memoria del proceso (es útil usar algo como Process Explorer para encontrar el ID de proceso correcto para volcar):
ADPLUS -hang -p <process id> -o .Esto creará un directorio que contiene el volcado de memoria. Ahora puede usar windbg y abrir el archivo de volcado (Archivo -> Abrir volcado de bloque ...)
Las alegrías del código no administrado ahora aparecen. Pero utiliza algo llamado Son of Strike, que comprende el código .NET, para ver qué objetos se asignan. Primero carga SOS:
.loadby sos mscorwks
Y luego le pides que examine el montón administrado:
!dumpheap -stat
En general, arroja un montón de resultados, pero hay dos columnas que muestran el número de instancias y la cantidad de memoria que se consume, por tipo. Algunos tipos que esperas ver mucho (por ejemplo, String), pero si, por ejemplo, hay miles de instancias de uno de tus propios tipos, podrías estar filtrando estos objetos de alguna manera. Uno que me atrapó en el pasado es conectar un controlador de eventos en un objeto a un evento estático en la aplicación, ese evento tiene una referencia en vivo para cada uno de esos objetos.
Nunca puedo recordar cómo funciona la mayoría de estos, y generalmente me refiero a esta hoja de trucos para SOS
Tess Ferrandez tiene un buen blog que a veces cubre la depuración de .NET usando los depuradores no administrados
Por ejemplo, una publicación de mayo pasado , que detalla un posible problema si utiliza XmlSerializer s con un constructor no predeterminado.
Hay muchos perfiladores de memoria por ahí.
Uno popular es DotTrace , otro es el perfilador de memoria ANTS , ambos son ofertas comerciales.
Puede bajar a un nivel muy bajo sin pagar por una herramienta de terceros. Esto no es para los débiles de corazón sin embargo.
Una pérdida de memoria .Net para ASP se limitará a todo lo que persista. Estado de la aplicación y, en menor medida, estado de la sesión.
Todo lo que funcione dentro de estas áreas es el primero en verificarlo.
Además, objetos estáticos en cualquier clase, especialmente listas o cualquier cosa del género.
También puede intentar usar el perfil de asp.net web . Es una herramienta gratuita que le permite ver información tal como está almacenada en la memoria mientras se ejecuta la aplicación.
Esto le permite analizar la caché asp.net, ver todas las sesiones actuales y el contenido del estado de la aplicación.