2009-07-24 10 views
6

Mi aplicación usaba 150 MB de memoria no hace mucho tiempo, ahora está en 286 mb. Lentamente sube, así que me olvido de deshacerme de algo. Esto no es un gran problema para mí, ya que tengo 4 GB pero quiero enviar esto a otros que solo tienen 1 GB de ram. Luego, pasando por el código, línea por línea, ¿cómo puedo encontrar objetos que necesitan ser eliminados o simplemente objetos grandes en general?¿Cómo encontrar soluciones y problemas de memoria? C#

Respuesta

2

Echa un vistazo a .NET Memory Profiler. Hay una prueba de 15 días y vale la pena pagar la licencia.

identificar fácilmente pérdidas de memoria por recopilación y comparación de instantáneas de instantáneas de memoria .NET incluyen datos sobre la instancia asignaciones .NET e instancias en vivo en el momento se recogió el instantánea. Proporcionan una gran cantidad de información útil y la hacen fácil de identificar las posibles fugas de memoria , especialmente cuando se comparan dos instantáneas .

1

También puede utilizar WinDbg y SOS. Éstos tienen la ventaja de ser gratuitos y muy, muy minuciosos, si es un poco complicado acostumbrarse.

Aquí hay un blog post que describe el proceso.

+2

windbg y SOS son mis favoritos también. Hay una publicación de blog mucho más antigua de Rico Mariani: http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx –

+0

Esa fue la publicación que me enganchó a SOS originalmente ... Pero el que publiqué creo que es un poco más fácil de seguir. –

4

Extendiendo las respuestas de JP y Reed.

Quería aclarar un poco de confusión. Si observa aumentos significativos en la memoria, es poco probable que el problema sea invocar a Dispose. Dispose generalmente se usa para liberar recursos no administrados como identificadores. Estos no ocupan mucha memoria, sino que son más valiosos como recursos.

Los aumentos en la memoria generalmente se asocian con objetos grandes o colecciones accesibles desde un objeto gestionado que se enruta directa o indirectamente a través de un objeto de pila o un controlador fuerte de GC. Esta es el área en la que probablemente quiera enfocar su investigación.

+0

Sí, este es un gran punto. Utilizo el generador de perfiles de memoria para realizar cosas como "¡oh, esa colección no debería crecer más y más para siempre!" :) –

+2

Además, eche un vistazo a cualquier evento al que se suscriba. El evento contiene una referencia al suscriptor, y si nunca se da de baja, esa referencia nunca se elimina. – JulianR

0

Salida this link

Stephen Toub entra en gran longitud para explicar diversas técnicas para hacer esto, A continuación se presentan algunas breves aspectos más destacados de su artículo

  • Al añadir un finalizador con fines de depuración, puede introducir una forma de averiguar cuándo una clase no fue eliminada adecuadamente, si el finalizador nunca se invoca, usted kno w que dispuestos no fue llamado

  • Para obtener información adicional acerca de la instancia, etc threadIds para ayudar en la reducción a la que instancia carecía de que está dispuesto invocada, se crea una clase FinalizationDebgger la que su clase desechable haría mantener a la cual llamará la instancia de la clase Disposición de la FinalizationDebugger cuando está dispuesta. Si no se llama Desechar el la instancia de clase, entonces cuando el finalizador lo dirige invocará el finalizador de ejemplo FinalizationDebgger en donde usted podría valer o lanzar una excepción para ayudar a depurar el problema ,

  • Mover todo el seguimiento código relacionado en una clase base que su clase desechable luego heredaría, lo que hace que el código sea mucho más limpio. Este enfoque puede o no funcionar ya que quema una clase base y si ya está heredando de otra base.

  • En la última opción, todo se descompone en una clase estática a la que llaman sus instancias . El FinalizationDebugger se convierte en una clase estática que expone tres métodos estáticos : Constructor, Dispose y Finalizer. La idea es que llame a estos métodos desde el lugar apropiado de su clase (dispose/finalize/constructor). Esto es mínimamente invasivo en su código, ya que normalmente implica agregar solo tres líneas de código. Todos los de estos métodos están marcados con una AtribuciónCondicional de modo que su clase solo los llamará cuando compile su clase en el modo DEPURAR.

Stephen también explica los pros y los contras de cada uno de sus enfoques. Las soluciones presentan varias opciones y deberá evaluarlas para determinar cuál funciona mejor para su situación. A DEBE leer IMHO

Espero que esto ayude.

+0

Necesito completar la respuesta para obtener votos. Simplemente señalar un enlace no es lo suficientemente bueno porque si el enlace se va, esta ya no es una respuesta útil. –

+0

Bastante justo, editando la respuesta para incluir un breve resumen de lo que se cubre en el artículo de MSDN –

0

Pruebe también ANTS Memory Profiler. Hay una versión de prueba completamente funcional de 14 días, y realmente me gusta la interfaz de usuario.

Divulgación: patrocinan el código de pastoreo en este momento, razón por la cual lo probé. Pero estoy realmente impresionado con eso: realicé un perfil de una aplicación durante 30 horas y obtuve toneladas de información útil. La interfaz de usuario es realmente útil: te guía a través del proceso y parece muy difícil.

alt text http://www.red-gate.com/products/ants_memory_profiler/images/object_retention_graph.gif

0

Éstos son par de trucos utilizando el ANTS Memory Profiler para ayudar a encontrar objetos no vendida y corregir las fugas.

  1. las hormigas perfilador de memoria permite que un filtro que se establece que muestran sólo objetos que contienen un método Dispose(). Enciéndalo, y estará dada una lista de objetos en vivo que no han sido desechados.

  2. Si bien la búsqueda de objetos no expuestos es útil, aún más útil es saber por qué estos objetos no se eliminan. Encontrar dónde se crean estos objetos no expuestos va un largo camino para encontrar el motivo de la fuga. Si puede cambiar el código del objeto con fuga, un truco útil de es introducir un campo para contener un stacktrace, y poblar este campo en el momento de la construcción del objeto. Entonces, debido a que el perfilador de memoria ANTS le permite inspeccionar campos de objetos, , puede simplemente leer la pila como era en el momento en que se crearon los objetos con fugas. Esto le dará una pista clara sobre quién debe ser el propietario de los objetos que gotean, y cómo deben llamar a Dispose sobre los objetos de los que son responsables.

Cuestiones relacionadas