Pregunta Por qué el resultado "Ver montón" no coincide con "Uso de memoria de proceso" en Visual Studio


Estoy intentando usar Visual Studio para rastrear el uso de la memoria en mi aplicación. En la ventana 'Herramientas de diagnóstico', muestra que mi aplicación usa 423 MB. Gracias a 'Memory Usage' y 'ViewHeap', cuando hago clic en la instantánea, obtengo una tabla del tamaño de mis objetos.

enter image description here

Pero cuando agrego esos números: = 3317228 + 403764 + 354832 + 264984 + 244836 + 195748 + 144032 + 28840 + 16452 + 13920 + 13888 + 3428 + 2100 + 20 = 5004072 = 4.77 MB

Mi pregunta es por qué este número 4.77MB no coincide con el 423MB que veo en la Tabla de "Memoria". Espero ver en la tabla de la izquierda un desglose de dónde fueron 423 MB. Por favor dime que me estoy perdiendo?


21
2018-06-02 19:21


origen


Respuestas:


¿Por qué el tamaño del Heap View no coincide con el tamaño de la tabla de memoria?

Hay docenas de posibles razones para esto, incluyendo Estar nervioso, Herramientas de depuración, Debug Symbols, Solo mi código, Recolección de basura et al. Pasaremos por dos de los grandes.

Solo mi código

los Solo mi código característica de Visual Studio tiende a esconder asignaciones, excepciones, puntos de interrupción y cualquier otro metadato sin código del usuario, que no se cargó desde un .PDB archivo o un proyecto abierto. Ver MSDN Just My Code para detalles.

Depuración de símbolos y herramientas

Cuando se depura alguna proyecto en Visual Studio, el Visual Studio Debugger ejecuta y asigna memoria extra para permitir puntos de ruptura, captura de excepcióny otras características Para cierto captura de herramientas de diagnóstico, debe usar Alt+F2 opción, o Depurar> Iniciar herramientas de diagnóstico sin depurar .... También querrás cambiar a Lanzamiento modo para esta parte. Solo este paso cortó la memoria que el gráfico mostraba (para mí) desde 21.5MiB a 5.5MiB, lo que indica que Símbolos de depuración y Herramientas de depuración zona sustancial factor. Recuerde, para que Visual Studio pueda detectar excepciones, puntos de interrupción y otros datos, debe adjuntarse a su proceso, y a todos los objetos dentro de su proceso.

Entonces, ¿cómo hacemos que estos números coincidan?

Realmente no deberías preocupación sobre los números que coinciden. El objetivo del gráfico de memoria y el gráfico de vista del montón es permitirle ver picos y fluctuaciones de memoria impares, que podrían indicar la incorrección del programa. Debería buscarlos, en lugar de centrarse en la diferencia entre los dos valores.

Dicho esto, hay algunos pasos que puede tomar para obtener preciso resultados.

Verdaderamente haciendo juego con los números

Si tu verdaderamente quiero unirlos, no creo que se pueda hacer de la manera que desees. Sin embargo, puedes acercarte. El primer paso es Inicie las herramientas de diagnóstico sin depurar ..., luego selecciona Uso de memoria. Una vez seleccionado, haga clic en Configuración Gear al lado, y asegúrese Tipo de Profiler es Mixed (Managed and Native). Luego, haz clic comienzo y tomar un poco instantáneas para que pueda examinar el uso de la memoria. Una vez hecho esto, detenga su depuración y examine su memoria.

Para examinar su memoria, haga clic en arriba a la izquierda número azul en el cuadro de instantáneas para la instantánea que desea examinar. En esta página, haga clic en Icono de rejilla sobre el parte superior derecha y deseleccionar ambos Solo mi código y Contraer objetos pequeños. Cambiar a la Heap nativo pestaña y hacer lo mismo, anulando la selección Solo mi código y entonces seleccione Incluir asignaciones liberadas.

Debería encontrar que esto solo hace que su error se acerque mucho más al valor real. (El valor real es el Bytes privados y el error es el Tamano de la pila) Con la aplicación en la que lo probé, trajo el total (de ambos montones) a aproximadamente 1.0265MiB, que era aproximadamente el mismo que la asignación indicada por Administrador de tareas cuando ejecuté el programa fuera de Visual Studio (este valor real era 1.1211MiB, pero con números tan pequeños se espera ese margen de error).

Que hace Incluir asignaciones liberadas ¿media? Esencialmente, cuando el GC borra la memoria, esa memoria es no eliminado inmediatamente desde el espacio de la aplicación. En su lugar, se libera para su uso por otros objetos, pero puede aún permanecen con la aplicación. Recolección de basura es un tema complicado y mucho más allá del alcance de esta pregunta y respuesta.

Notas adicionales

La asignación, el uso y la medición de la memoria es una muy tema complejo. Desafortunadamente, no hay muchas formas 100% infalibles para manejar situaciones como esta, y generalmente cuanto más infalible y precisa es la solución, más compleja, lenta y difícil de usar es.

Referencias

MSDN Just My Code: https://msdn.microsoft.com/en-us/library/dn457346.aspx#BKMK__NET_Framework_Just_My_Code

Recolección de basura de MSDN: https://msdn.microsoft.com/en-us/library/0xy59wtx%28v=vs.110%29.aspx

El resto de esta respuesta se basa en mi propia experimentación y prueba y error, y está sujeto a posibles imprecisiones que pueden resultar de diferentes ambientes. Los pasos presentados aquí podría no trabajo para todos los desarrolladores, y se realizaron con Visual Studio 2015 RC versión 14.0.22823.1 D14REL.


25
2018-06-02 20:26



El gráfico muestra bytes privados para todo el proceso. Esto incluye el montón administrado, el montón nativo, las pilas, etc. Consulte esta respuesta para obtener más información sobre los tipos de métricas de memoria: ¿Qué son los bytes privados, los bytes virtuales, el conjunto de trabajo?

La tabla Heap View solo muestra los tipos activos (no se pueden recolectar basura) en el montón administrado en el momento en que se tomó la instantánea. Para ver los tipos en los montones nativos y gestionados, cambie a la depuración de modo mixto. La Vista de montón (y el número en la tabla de instantáneas) son un subconjunto de la memoria de proceso que se muestra en el gráfico.

La herramienta integrada de depurador funciona mejor para tratar de encontrar la causa de un crecimiento inesperado en la memoria, o rastrear objetos que deberían haber sido recogidos, pero que tienen referencias que aún los mantienen vivos.

Aquí hay una publicación de blog que escribí (trabajo para MSFT) en la herramienta de memoria que explica cómo rastrear objetos con referencias desactualizadas: http://blogs.msdn.com/b/visualstudioalm/archive/2015/04/29/diagnosing-event-handler-leaks-with-the-memory-usage-tool-in-visual-studio-2015.aspx


4
2017-07-25 21:51