.NETO de la fragmentación del Montón cuando se utiliza MSMQ async IO

Question

Tengo una aplicación que se lee de gran cantidad de colas MSMQ(alrededor de 10000 en el momento).Yo uso queue.BeginPeek con UInt32.MaxValue tiempo de espera para recibir el mensaje de la cola.Cuando aparezca el mensaje en la cola, proceso y llamar a queue.BeginPeek de nuevo.Así que escuchar a todas las colas, pero el procesamiento de los mensajes se realiza en el Hilo de la Piscina.

Me di cuenta de que el uso de la memoria crece lentamente(dos semanas de trabajo que causan el crecimiento de 200 a 800 MB).Después de investigar el archivo de volcado veo típico de la fragmentación del montón imagen con muchos objetos libres (algunos de ellos tienen un tamaño de unos varios megabytes).Y no se clavan objetos entre los agujeros.

Esta parece ser una situación común cuando se trabaja con llamadas a código no administrado, que crear objetos anclados.Pero no encontré ninguna solución en internet.

Así es la gestión de la memoria en .NET tan puro, que no permite que incluso tales escenarios simples, o me olvido de algo?

Editar : He hecho algunas investigaciones en aplicaciones de ejemplo.Los agujeros(libre de zonas de memoria, por lo que se llama libre de objetos) entre cubrió los objetos son reutilizados por GC a la hora de asignar memoria para los objetos nuevos.Pero en mi aplicación de producción, fijar los objetos son de larga vida, y que finalmente aparecen en la 2ª generación con los agujeros entre ellos(porque GC sólo se desplaza la frontera que separa a las generaciones).Como tengo muy poco normal de larga vida-objetos, veo que esto de los agujeros en la 2ª generación de archivo de volcado.

Así que el consumo de memoria de mi aplicación se puede crecer a 10000*(promedio de tamaño del agujero).(10000 es el número de colas que también puede aumentar en el futuro).No tengo ideas de cómo solucionar este problema en el momento.La única forma es reiniciar la aplicación a partir de tiempo al tiempo.

Una vez más sólo puedo preguntar, ¿por qué .NETA no se han separado montón de fijado de los objetos?(tal vez esta es la pregunta de novato).En el momento en que veo que llamar a las operaciones asincrónicas que trabajar con código no administrado puede causar problemas de memoria.

Answer 1

Después de mirar el código fuente para el contenedor administrado por MSMQ parece que ha tropezado con un problema real utilizando la API.Llamar BeginPeek va a crear una colección de propiedades que luego se cubrió antes de pasar a la API no administradas.Sólo cuando se recibe un mensaje son estas propiedades desprendida, pero para seguir recibiendo los mensajes que usted tiene que llamar BeginPeek en este punto conduce a la fragmentación de la memoria a lo largo del tiempo.

Si esta fragmentación es una preocupación real el único hack que se me ocurre es que cada hora o así que usted debe cancelar todas las llamadas a BeginPeek, la fuerza de una recolección de basura y, a continuación, reanudar la escucha normal de las operaciones.Esto debería permitir que el recolector de elementos no utilizados para controlar la fragmentación.

Answer 2

Bueno, si es un problema con los objetos anclados ser de larga duración, a continuación, un simple trabajo de todo sería el uso de un tiempo de espera en la BeginPeek con una duración más corta para evitar que se muevan en la próxima generación.Después de cada tiempo de espera y EndPeek usted puede volver a emitir el BeginPeek.Dependiendo de las propiedades que Martin nos referimos son creados y eliminados, puede volver a crear el objeto de cola (no la propia cola obviamente, sólo el amanged contenedor).Aunque con suerte no tendrás que llevarlo a ese extremo.