¿Cómo uso un archivo de volcado para diagnosticar una pérdida de memoria?

Question

Tengo un servicio .NET con un conjunto de trabajo privado normal de aproximadamente 80 MB. Durante una prueba de carga reciente, el proceso alcanzó un consumo de memoria de 3,5 GB, lo que provocó que toda la máquina tuviera poca memoria física (se utilizaron 3,9 de 4 GB) y la memoria no se liberó mucho después de que se detuviera la prueba de carga. Utilizando el administrador de tareas, tomé un archivo de volcado del proceso y lo abrí en Visual Studio 2010 SP1, y puedo comenzar a depurarlo.

¿Cómo puedo diagnosticar el problema de memoria? Tengo dotTrace Memory 3.x a mi disposición, ¿admite perfiles de memoria en archivos de volcado? De lo contrario, ¿las funciones de creación de perfiles de memoria de Visual Studio 2010 Premium serán de ayuda (actualmente tengo Professional)? ¿Puede WinDbg ayudarme?

ACTUALIZACIÓN: El nuevo Visual Studio 2013 último puede ahora de forma nativa diagnosticar problemas de memoria que utilizan archivos de volcado. Ver this blog post para más detalles.

Answer 1

Instalar WinDbg. Debe asegurarse de obtener la versión correcta x86 o x64 según su volcado. Aquí hay un enlace directo al download para x86.

En eso, debe asegurarse de haber realizado el volcado correcto. Puede usar el Administrador de tareas para crear el archivo de volcado (haga clic derecho en proceso -> Crear archivo volcado). Si tiene 64 bits y su proceso es x86, use la versión de 32 bits del Administrador de tareas (C: \ Windows \ SysWOW64 \ taskmgr.exe) para tomar el archivo de volcado. Consulte my article para obtener más información sobre cómo tomar archivos de volcado, por ejemplo, si tiene XP y necesita usar windbg para crear el archivo de volcado.

advertencia hay una curva de aprendizaje bastante empinada y es posible que las cosas no funcionen exactamente como se describe aquí, así que vuelva con cualquier problema.

Supongo que está utilizando .NET4 dado que puede abrir el volcado en Visual Studio. Aquí hay una muy guía rápida para ayudarle a trabajar con su archivo DMP:

1) Ejecutar WinDbg, set de ruta símbolos (Archivo -> Símbolo Ruta de búsqueda) a

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols 

2) de descarga de bloqueo abierto o arrastre su archivo .DMP a WinDbg.

3) tipo esto en la ventana de comandos

.loadby sos clr 

(FYI, para .NET 2, el comando debe ser .loadby sos mscorwks)

4) a continuación, escriba este

!dumpheap -stat 

que enumera el tipo de objetos y su conteo. se ve algo como esto:

Tendrá que analizar esto en el contexto de su aplicación y ver si hay algo inusual aparece.

Hay mucho más para windbg, google es tu amigo.

Answer 2

http://msdn.microsoft.com/en-us/library/ee817660.aspx

Microsoft tiene una guía aquí. Sin embargo, es demasiado difícil para principiantes.

dotTrace puede generar gráficos de memoria visual (mejor que WinDbg), pero nunca los use para volcados.

Answer 3

Generalmente, si tiene una fuga en una aplicación administrada, significa que algo no se está recopilando. Las fuentes comunes incluyen

• Manejadores de eventos: si el suscriptor no se elimina, el editor se aferrará a él.

• Estática

• finalizadores: un finalizador bloqueado impedirá que el subproceso finalizador se ejecute cualquier otro finalizadores y así evitar estos casos de ser recogido.

• De forma similar, un hilo estancado se mantendrá en las raíces que contenga. Por supuesto, si tienes hilos bloqueados que probablemente afectarán a la aplicación en varios niveles.

Para resolver este problema, debe inspeccionar el montón administrado. WinDbg + SOS (o PSSCOR) te permitirá hacer esto. El comando !dumpheap -stat enumera todo el montón administrado.

Debe tener una idea del número de instancias de cada tipo que se esperan en el montón. Una vez que encuentre algo que parece extraño, puede usar el comando !dumpheap -mt <METHOD TABLE> para listar todas las instancias de un tipo dado.

El siguiente paso es analizar la raíz de estas instancias. Elija uno al azar y haga un !gcroot en eso. Eso mostrará cómo está enraizada esa instancia particular. Busque controladores de eventos y objetos anclados (generalmente representan referencias estáticas). Si ve la cola del finalizador allí, necesita examinar qué está haciendo el hilo del finalizador. Use los comandos !threads y !clrstack para eso.

Si todo se ve bien para esa instancia, pasará a otra instancia. Si eso no produce nada, es posible que deba volver a mirar el montón nuevamente y repetir desde allí.

Otras fuentes de fugas incluyen: Conjuntos que no están descargados y fragmentación del gran montón de objetos. SOS/PSSCOR puede ayudarlo a localizar estos también, pero omitiré los detalles por el momento.

Si quiere saber más, recomiendo Tess' blog. También hice un par de videos sobre cómo usar WinDbg + SOS (here y here).

Si tiene la opción de depurar el proceso mientras se ejecuta, le recomiendo usar PSSCOR en lugar de SOS. PSSCOR es esencialmente una rama privada de las fuentes SOS que se ha mejorado con comandos adicionales y muchos de los comandos SOS existentes también se han mejorado. P.ej. La versión PSSCOR del comando !dumpheap tiene una columna delta muy útil, lo que hace que la solución de problemas de pérdida de memoria sea mucho más fácil.

Para utilizarlo, necesita iniciar su proceso, conectar WinDbg y cargar PSSCOR y hacer un !dumpheap -stat. Luego, permite que el proceso vuelva a ejecutarse para que se realicen asignaciones. Rompe la ejecución y repite el comando. Ahora PSSCOR le mostrará el número de instancias que se agregaron/eliminaron desde la inspección anterior.

Answer 4

Desde la versión 2017.2 JetBrains dotMemory admite el análisis de volcados de memoria de Windows con toda su potencia y elegante GUI.