Recolector de elementos no utilizados .NET y memoria virtual x64

Question

Ejecutar una aplicación .NET en Windows Server 2008 x64 con 16 GB de RAM. Esta aplicación necesita buscar y analizar una gran cantidad de datos (aproximadamente 64 GB), y mantener todo en la memoria a la vez.

Lo que espero ver: El tamaño del proceso se expande más allá de 16GB a 64GB. Windows usa memoria virtual para enviar los datos extra a/desde el disco según sea necesario. Este es el clásico caso de uso de la memoria virtual.

Lo que realmente veo: El tamaño del proceso está limitado a la cantidad de memoria física (16 GB). La aplicación pasa el 99.8% de su tiempo en el recolector de basura.

¿Por qué nuestra aplicación no puede utilizar la memoria virtual? ¿Es esto un problema en la configuración del recolector de basura .NET o en el administrador de memoria virtual x64 de Windows mismo? ¿Qué puedo hacer para que nuestra aplicación use memoria virtual en lugar de limitarse a la memoria física?

Gracias.

- Brian

Actualización: Me han escrito un programa muy pequeño que presenta el mismo comportamiento:

using System; 

namespace GCTest 
{ 
    class Program 
    { 
     static void Main() 
     { 
      byte[][] arrays = new byte[100000000][]; 
      for (int i = 0; i < arrays.Length; ++i) 
      { 
       arrays[i] = new byte[320]; 
       if (i % 100000 == 0) 
       { 
        Console.WriteLine("{0} arrays allocated", i); 
        System.Threading.Thread.Sleep(100); 
       } 
      } 
     } 
    } 
} 

Si quieres probarlo, asegúrese de construir para x64. Puede que tenga que modificar las constantes un poco para estresar su sistema. El comportamiento que veo es que el proceso se atasca a medida que se acerca a un tamaño de 16 GB. No hay mensaje de error o excepción lanzada. El monitor de rendimiento informa que el% del tiempo de CPU en GC se aproxima al 100%.

¿No es esto inaceptable? ¿Dónde está el sistema de memoria virtual?

Answer 1

Parece que no está manteniendo una referencia a los datos de gran tamaño. El recolector de basura no recogerá objetos referenciados.

Answer 2

¿Ha comprobado para asegurarse de que su archivo de paginación está configurado para que pueda expandirse a ese tamaño?

actualización

He estado jugando con esto un poco con el ejemplo dado, y esto es lo que veo.

Sistema: Windows 7 64bit, 6 GB de RAM de triple canal, 8 núcleos.

1. Necesita un archivo de paginación adicional en otro eje desde su SO o este tipo de investigación manguera su máquina. Si todo está peleando por el mismo archivo de paginación, empeora las cosas.

2. Veo una gran cantidad de datos promovidos de generación en generación en el GC, más una gran cantidad de GC sweeps \ collections y una gran cantidad de fallas de página como resultado de los límites de la memoria física. Solo puedo suponer que cuando la memoria física se agote \ muy alta, esto desencadena barridos y promociones de generación, lo que provoca que se toque una gran cantidad de memoria paginada que conduce a un spriral de muerte a medida que se localiza la memoria tocada y otra memoria es forzado a salir. Todo termina en un desastre húmedo. Esto parece ser inevitable cuando se asigna una gran cantidad de objetos de larga vida que terminan en el Heap Small Object Heap.

Ahora comparar esto con la asignación de objetos de una manera destinará directamente en el montón de objetos grandes (que no sufre los mismos problemas de barrido y de promoción):

private static void Main() 
{ 
    const int MaxNodeCount = 100000000; 
    const int LargeObjectSize = (85 * 1000); 

    LinkedList<byte[]> list = new LinkedList<byte[]>(); 

    for (long i = 0; i < MaxNodeCount; ++i) 
    { 
     list.AddLast(new byte[LargeObjectSize]); 

     if (i % 100000 == 0) 
     { 
      Console.WriteLine("{0:N0} 'approx' extra bytes allocated.", 
       ((i + 1) * LargeObjectSize)); 
     } 
    } 
} 

Esto funciona como decir esperada la memoria virtual se usa y luego se agota: 54 GB en mi entorno \ configuración.

Parece que la asignación de una masa de objetos pequeños de vida larga eventualmente conducirá a un círculo vicioso en el GC ya que las barridas de generación y las promociones se realizan cuando se agotó la memoria física: es una espiral de muerte de archivo de página.

Actualización 2

Mientras que investiga el problema que jugaba con una serie de opciones \ configuraciones que no hizo ninguna diferencia apreciable:

• Forzar el modo GC servidor.
• Configurando GC de baja latencia.
• Varias combinaciones de forzar GC para intentar amortizar GC.
• Conjuntos de trabajo de proceso Min \ Max.