2011-06-26 12 views
9

He visto algunas discusiones similares a esta pregunta, pero nada que realmente responda el problema que estoy enfrentando.¿Comprobación rápida o limitación del uso de memoria de subprocesos en .NET?

Estoy trabajando en una aplicación C# donde el comportamiento del software se puede personalizar a través de scripts interpretados. Cada script se ejecuta en un subproceso secundario diferente de la aplicación C#. (Estoy usando el intérprete de JavaScript de Jint para ejecutar los guiones, pero mi pregunta es igualmente válida para cualquier otra circunstancia bajo la cual un subproceso podría comportarse dinámicamente en una aplicación .NET). Hasta ahora esto está funcionando bien. Pero necesito asegurarme de que la aplicación se comporte bien. En el caso de una secuencia de comandos incorrecta que podría hacer que la aplicación se quede sin espacio en el montón, necesito la capacidad de detectar y detener cualquier hilo que consuma demasiada memoria. Conceptualmente, esto podría verse como algo similar a un navegador web que determina si javascript en una página lleva demasiado tiempo o demasiada memoria para ejecutar. El problema es que no he podido determinar si hay alguna manera de hacerlo en .NET.

¿Hay alguna manera en que puedo poner un límite estricto a la cantidad de memoria que puede utilizar un hilo, o verificar rápidamente la utilización de la memoria del hilo desde un hilo padre? No me preocupa el desbordamiento de pila dentro del hilo, solo espacio de montón. La solución "obvia" sería dividir la interpretación en procesos separados en lugar de separar hilos, pero eso implicaría un impacto de rendimiento significativo para mi aplicación ya que estos scripts modifican el comportamiento del software y por lo tanto están destinados a ser estrechamente acoplado. El monitoreo de nivel de aplicación tampoco sería ideal ya que no proporcionaría información sobre qué script no se está comportando por sí mismo. Además, un método lento para la depuración no funcionará, ya que los scripts están diseñados para permitir una rápida modificación del software en lugar de tener que construir, probar y volver a implementar. Simplemente necesito una forma bastante rápida para detectar un hilo que está consumiendo demasiada memoria, así que puedo matar e ignorar su script.

Gracias!

+0

"Estoy trabajando en una aplicación C# donde el comportamiento del software se puede personalizar a través de scripts interpretados. Cada script se ejecuta en un hilo hijo diferente de la aplicación C#" -? Si todo lo que estás haciendo es personalizar la aplicación. ¿Por qué los scripts necesitan ejecutarse en hilos separados? –

+0

"ya que estos scripts modifican el comportamiento del software y por lo tanto están destinados a ser estrechamente acoplados" - Oigo las palabras scripts estrechamente acoplados y empiezo a preguntarme sobre el diseño ... –

+0

Si quiere limitar el uso de la memoria, entonces creo que es mejor usar procesos separados. Si existe el peligro de que algún script no tenga absolutamente ningún control sobre no jugar, entonces me aseguraré de que se ejecute en un proceso separado de todos modos. No estoy seguro de que pueda limitar la forma en que desea por hilo, ya que, si hay alguna API disponible para hacerlo, será una API de Windows, y hasta donde yo sé, no puede mapear los hilos gestionados y los hilos de Windows para ello ser de alguna utilidad. – InBetween

Respuesta

0

WMI es una opción para usted. Sé con certeza que puede supervisar el uso de la memoria de proceso. Pero puedes explorar esta idea más.

Here is small intro to WMI in C#. Hay un conjunto completo de clases que puede consultar. Y para consultar las estadísticas locales de la máquina, no va a ser muy caro. Pero recomendaría tomar algunos números de rendimiento primero.

+0

El problema de este enfoque, creo, es que no hay una relación de uno a uno entre los subprocesos administrados y los subprocesos de Windows. – InBetween

3

Como otros carteles sugieren, puede ser más fácil de alojar en un proceso separado. Un enfoque ligeramente más liviano sería alojar en un dominio de aplicación separado y usar la API app-domain resource monitoring para monitorear el uso de la memoria.

Cuestiones relacionadas