¿Puedo (y alguna vez quiero) establecer el tamaño máximo de almacenamiento dinámico en .net?

Question

Viniendo de un fondo java, una de las cosas a las que estoy acostumbrado es decirle a la JVM cuál debería ser el tamaño máximo de almacenamiento dinámico. Si el programa en ejecución intenta tragar más de lo permitido, y el recolector de basura no puede liberar más recursos, entonces se lanza OutOfMemoryError y todo explota. Por lo tanto, establecer el tamaño máximo de almacenamiento dinámico es importante en Java.

¿Se aplica esto en .net? ¿Puede establecer los límites de tamaño de almacenamiento dinámico? ¿El CLR sigue creciendo hasta llegar a los límites físicos de la máquina? ¿O no es un problema en .net por alguna razón sutil que mis parpadeos de Java me impiden ver?

Answer 1

No puede establecer el tamaño máximo de almacenamiento dinámico en .Net a menos que aloje el CLR usted mismo en un proceso.

Editar: Para controlar las asignaciones de memoria de CLR, incluido el tamaño máximo de almacenamiento dinámico, debe usar la API de host para alojar el clr y usar específicamente las '' interfaces de administrador de memoria '', puede encontrar información de arranque aquí MSDN Magazine, columna CLR Inside Out: API de alojamiento CLR

Editar: para responder a su pregunta, ¿por qué desea controlar la asignación de memoria o específicamente el tamaño máximo de almacenamiento dinámico? Por lo general, no desea hacerlo, pero si está escribiendo una aplicación que es como SQL Server o IIS o alguna aplicación en tiempo real, entonces tendría una buena razón para tener control sobre la memoria y específicamente, evitar la paginación, de lo contrario, el CLR en sí y el sistema operativo ya hacen un trabajo bastante bueno para usted, y lo que queda es para garantizar que su aplicación utilice recursos mínimos para que las cosas funcionen bien.

Answer 2

No, no se aplica en .NET. El montón sigue creciendo hasta que ya no puede crecer más. (Obviamente, esto es "después de intentar recuperar la memoria a través de GC, hacer crecer el montón".) Básicamente, no hay tanta afinación disponible en .NET GC como en Java. Puede elegir el GC del servidor o el cliente, y creo que hay una opción para activar / desactivar el GC concurrente (encontraré enlaces en un minuto), pero eso es todo.

EDITAR: Parece que hay un poco más, aunque no una gran cantidad. entrada del blog de Rick Minerich sobre la configuración de GC y el siguiente parece saber más que yo sobre el asunto. Probablemente son un buen punto de partida para cualquier investigación adicional, pero en su mayoría son indicadores en lugar del tipo de límites de memoria disponibles en las JVM.

EDITAR: la respuesta de Pop plantea un buen punto: he estado asumiendo un " normal " Modelo de alojamiento CLR (es decir, no está bajo su control). Si desea hacer el esfuerzo de alojarlo usted mismo, es probable que obtenga mucho más control, a costa del trabajo adicional de alojarlo. No puedo decir que haya investigado ese lado de las cosas.

Answer 3

Es posible que desee ver System.Runtime.MemoryFailPoint .

Answer 4

Por lo que he encontrado, no hay una manera simple de controla el tamaño del montón de una aplicación .Net usando el CLR.

El enlace de arriba solo la mitad responde la pregunta. Cuando investigué este mismo problema, la respuesta es "El montón crece para usar toda la memoria disponible". como si esa fuera la única razón por la que desea controlar el tamaño máximo de almacenamiento dinámico.

En entornos de servidor (típicamente Java), no desea que una aplicación con un mal comportamiento acapare la memoria a expensas de otras aplicaciones alojadas. Una solución simple es limitar la cantidad de memoria que la aplicación puede usar para su montón. Esto se logra con el argumento Java -Xmx para que pueda garantizar que la aplicación no usará más de lo planeado, p. -Xmx256M. Dado que la asignación de memoria en el montón durante la inicialización puede ralentizar el inicio de las aplicaciones, Java utiliza el argumento -Xms para permitir que las aplicaciones que realizan una gran cantidad de creación de objetos durante la inicialización comiencen con un gran bloque de montón en lugar de que la JVM cambie el tamaño del montón de forma constante. va.

.Net's CLR no tiene esta capacidad. Sospecho que es porque .Net CLR no es una máquina virtual. El CLR resulta ser una API (bastante completa, podría agregar) que sirve como un adaptador para .dlls nativos que equivalen a un enfoque mucho más parecido a un ejecutable cuando se trata de gestión de memoria.

Hice esta pregunta sobre el desarrollo de SharePoint y escuché que podría ser posible controlar el gran tamaño mediante el uso de módulos IIS llamados aplicaciones web, por lo que puede decirle a IIS que limite la memoria de una aplicación web determinada. Me pregunto si esto se debe a que IIS tiene rutinas personalizadas que reemplazan / anulan new () / malloc () / etc y, por lo tanto, pueden proporcionar este tipo de control a las aplicaciones del cliente. Eso significa que las aplicaciones .Net independientes no tienen suerte a menos que desee escribir un administrador de memoria personalizado en C ++ y crear una interfaz para .Net