Memoria máxima. Un proceso .NET puede asignar

Question

¿Cuál es la memoria máxima que el recolector de basura puede asignar para un proceso .NET? Cuando compilo en x64, Process.GetCurrentProcess.MaxWorkingSet arroja unos 1,4 GB, pero cuando compilo AnyCPU (x64) se devuelve el mismo número. Para x64 debería ser más parecido al valor "Límite" que se muestra en el Administrador de tareas. ¿Cómo puedo obtener el número correcto que causará OutOfMemory-Exceptions cuando se excede en todos los casos?

Algunos ejemplos lo que el método debe devolver:

1) Configuración de la máquina: 64 en Windows, la memoria física de 4 GB, 4 GB de archivo de página
-Como proceso de 64 bits: 8 GB
-Como proceso de 32 bits : 1,4 GB

2) Configuración de la máquina: 64 en Windows, 1 GB de memoria física, archivo de página 2 GB
-Como proceso de 64 bits: 3GB
-Como proceso de 32 bits: 1,4 GB

3) Configuración de la máquina: x32 en Windows, la memoria física de 4 GB, 4 GB de archivo de página
-Como proceso de 64 bits: No sucederá
-Como proceso de 32 bits: 1,4 GB

4) Configuración de la máquina: x32 en Windows, la memoria física de 512 MB, 512 MB de archivo de página
-Como proceso de 64 bits: no sucederá
-Como proceso de 32 bits: 1.0GB

Answer 1

¿no se depende de la cantidad de RAM que tiene ?

En teoría, un proceso x64 puede asignar EB's (etabytes?) De RAM, creo, es decir, MUCHO. Pero si lo hace, su máquina debería comenzar a paginar como loca y generalmente morir.

Era diferente en el modo de 32 bits, ya que no se podía asignar más de 1GB de RAM en CUALQUIER proceso en Windows (sí, hay formas de evitarlo, pero no es bonito). En la práctica, este precio de aproximadamente 7-800 meg por proceso .NET, como .NET reservó algo de espacio.

De cualquier manera, en 32 bits, lo máximo que puede usar es 3 GB: el sistema operativo reserva 1 GB de espacio virtual para sí mismo.

En 64 bits, debería ser 2^64, que es un número grande, pero http://en.wikipedia.org/wiki/X86-64 dice que es 256TB de espacio virtual y 1TB de RAM REAL. De cualquier manera, es mucho más de lo que probablemente tenga en su máquina, por lo que llegará al archivo de la página.

Con un OS de 64 bits y un tiempo de ejecución de 64 bits, aplicaciones basadas en 2,0 .NET pueden ahora utilizar 500 veces más memoria para los datos tales como cachés basadas en servidor.

Esto tiene buena información, también http://www.theserverside.net/tt/articles/showarticle.tss?id=NET2BMNov64Bit

Por cierto, si usted está en una máquina de 64 bits (es decir, la máquina x64 + OS x64), la compilación de Cualquier CPU y x64 hace lo mismo - que se ejecuta en modo x64. La única diferencia es si se utiliza VRS Cualquier CPU x86:

• SO x64/.NET, Cualquier CPU: app 64
• SO x64 /.NET, x64: app x64

• x64 OS .NET, x32 /: app x32 (x64 marco .NET como instalan ambas versiones x32 y x64 de la Fx)

• x32 OS/NET, Cualquier CPU: app x32

• x32 OS/.NET, x64: CRASH Y BURN BABY! (en realidad, simplemente muere con gracia)
• x32 OS/.NET, x32: x32 app.

Answer 2

Windows se puede configurar para asignar más espacio de archivos de página bajo demanda, o on request.
Job objects puede evitar el consumo de más de una cierta cantidad de memoria.
fragmentación del montón y la naturaleza generacional de la misma (además de la necesidad de poner cosas grandes en el objeto grande Montón)

Todo esto significa que el límite duro no es de mucha utilidad en la realidad y significa responder a la pregunta "¿cómo mucha memoria podría teóricamente asignar "es bastante más compleja de lo que piensas.

Dado que es cualquier complejo pidiendo a esa pregunta es probablemente tratando de hacer algo mal y debe reorientar su pregunta a algo más útil.

¿Qué estás tratando de hacer que parece necesitar tal pregunta?

"Sólo quiero saber cuando la carga actual de la memoria del proceso podría conseguir problemática así que puede tomar acciones como la liberación de algunos elementos de una memoria caché personalizado."

Derecha. esta es una pregunta mucho más tratable.

Dos soluciones en orden de complejidad:

1. Haga sus cachés utilizan WeakReferences
   • Esto quiere decir que las cosas van a ser liberados por el sistema casi mágicamente para usted, pero tendrá poco control sobre cosas como la política de reemplazo
   • esto se basa en los datos en caché es mucho más grande que la llave y la sobrecarga de una referencia débil
2. Regístrese para notification of Garbage Collections
   • Esto le permite tomar el control de liberar cosas.
   • confía en que el sistema tenga el tamaño máximo apropiado para las generaciones de GC, lo que puede tardar un tiempo en estabilizarse.

Puntos a tener en cuenta. ¿Es realmente menos costoso mantener esta memoria caché masiva (ir al disco por el sonido de la misma) que volver a calcular/volver a solicitar los datos?
Si su caché exhibe una localidad pobre entre los elementos solicitados comúnmente/consecutivamente, se gastará mucho esfuerzo buscando y retirando datos. Una memoria caché más pequeña con una política efectiva de reajuste ajustada tiene buenas posibilidades de desempeñarse considerablemente mejor (y con mucho menos impacto en otros programas en ejecución)

Como nota adicional: En .Net, ningún objeto de tamaño variable (cadenas, matrices) puede tener más de 2 GB de tamaño debido a las limitaciones de las estructuras centrales de CLR para la gestión de la memoria. (y cualquier solución anterior se beneficiará de esto)