La aplicación de larga duración se ralentiza

Hay una aplicación que consta de tres archivos ejecutables. Uno de ellos – un despachador, que ejecuta otros ejecutables. El despachador recibe un código de un ejecutable en su finalización. Es decir, solo el distribuidor siempre está en ejecución, otros ejecutables se descargan y se cargan nuevamente. La aplicación se ejecuta en el punto de servicio y funciona todo el día. En el primer lanzamiento la aplicación funciona rápido. Al final del día, la aplicación funciona terriblemente lenta. ¿Cuál podría ser la razón de tal comportamiento?

Podría haber muchas razones para una desaceleración con el tiempo. En cualquier lugar, desde una pérdida de memoria lenta hasta antivirus. Lo mejor que puede hacer es tratar de generar evidencia (datos) sobre qué área de la aplicación debe ver primero. Intenta no hablarlo con muchos desarrolladores porque todos tendrán una opinión diferente sobre lo que podría estar mal. Obtener los datos!

Cómo obtener los datos:

perfmon perfmon es tu amigo Puede ver muchos contadores (tanto para el sistema como para el proceso). Así que puedes comenzar por crear un perfil de los 4 grandes (eso es memoria, uso de disco, CPU y redes). Hay una gran cantidad de publicaciones sobre qué contadores son mejores, por lo que no voy a entrar en demasiados detalles sobre los contadores de rendimiento aquí.

windbg Si realmente ves que la memoria está creciendo y no se está recolectando, es hora de traer las armas grandes. .NET es excelente para abstraer el uso de memoria de los desarrolladores, pero esto significa que debemos ir por debajo de .NET a veces para descubrir qué es lo que no permite que el recolector de basura haga su trabajo. windbg con sos.dll (extensiones administradas) es una gran herramienta para esto. La parte más difícil de windbg (en mi experiencia) es conseguir que las extensiones sos se carguen correctamente. Debe prestar mucha atención a la architecture de destino (64 o 32) que está analizando y a qué versión de CLR está ejecutando.

procdump procdump by sysinternals es una pequeña gran utilidad para tomar instantáneas de memoria de un proceso en ejecución. Estas instantáneas (archivos .dmp) pueden ser analizadas por windbg.

sos El sos.dll se ha enviado con .NET Framework desde v2. Con v4, Visual Studio 2010 ha integrado sos y te permite analizar archivos .dmp.

Los comandos sos para las memory leaks que he encontrado más útiles son:

! eeheap -gc (descripción general de cada generación de cada montón)

! dumpheap -min (elimina todos los objetos y tipos, sobre un particular)

! dumpheap -type (volcar todos los objetos de un específico)

! gcroot

(imprime una stack para que pueda ver qué objeto principal está anclando en el GC)

! do

(imprime la memoria de un objeto específico)

Algunos otros punteros:

Por lo general, desea capturar la memoria de instantáneas bajo carga, por lo que sería bueno tener alguna forma de simular eso desde fuera del sistema. Por lo tanto, es bueno hacer que esto se ejecute antes de tiempo e incluso integrarlo en el proceso de control de calidad de la aplicación.

Para problemas de rendimiento, generalmente es mejor tomar instantáneas regulares a lo largo del tiempo con una aplicación en ejecución. Luego puedes comparar las instantáneas cuando analizas.

Bueno, eso fue un poco más largo de lo que pretendía, ¡pero espero que valga la pena!

Debe verificar el uso de memoria de su aplicación de despachador … parece que no está desechando objetos no utilizados.