strana eccezione di memoria esaurita durante la serializzazione

Question

Sto utilizzando VSTS2008 + C# + .Net 3.5 per eseguire questa applicazione console su x64 Server 2003 Enterprise con memoria fisica 12G.

Ecco il mio codice e trovo quando si esegue l'istruzione bformatter.Serialize (stream, table), c'è un'eccezione di memoria insufficiente. Ho monitorato l'utilizzo della memoria tramite la scheda Perormance di Task Manager e trovo che viene utilizzata solo la memoria fisica 2G quando viene generata un'eccezione, quindi non dovrebbe essere esaurita la memoria. :-(

Delle idee che cosa è sbagliato Qualsiasi limitazione di .Net serializzazione

static DataTable MakeParentTable() 
    { 
     // Create a new DataTable. 
     System.Data.DataTable table = new DataTable("ParentTable"); 
     // Declare variables for DataColumn and DataRow objects. 
     DataColumn column; 
     DataRow row; 

     // Create new DataColumn, set DataType, 
     // ColumnName and add to DataTable.  
     column = new DataColumn(); 
     column.DataType = System.Type.GetType("System.Int32"); 
     column.ColumnName = "id"; 
     column.ReadOnly = true; 
     column.Unique = true; 
     // Add the Column to the DataColumnCollection. 
     table.Columns.Add(column); 

     // Create second column. 
     column = new DataColumn(); 
     column.DataType = System.Type.GetType("System.String"); 
     column.ColumnName = "ParentItem"; 
     column.AutoIncrement = false; 
     column.Caption = "ParentItem"; 
     column.ReadOnly = false; 
     column.Unique = false; 
     // Add the column to the table. 
     table.Columns.Add(column); 

     // Make the ID column the primary key column. 
     DataColumn[] PrimaryKeyColumns = new DataColumn[1]; 
     PrimaryKeyColumns[0] = table.Columns["id"]; 
     table.PrimaryKey = PrimaryKeyColumns; 

     // Create three new DataRow objects and add 
     // them to the DataTable 
     for (int i = 0; i <= 5000000; i++) 
     { 
      row = table.NewRow(); 
      row["id"] = i; 
      row["ParentItem"] = "ParentItem " + i; 
      table.Rows.Add(row); 
     } 

     return table; 
    } 

    static void Main(string[] args) 
    { 
     DataTable table = MakeParentTable(); 
     Stream stream = new MemoryStream(); 
     BinaryFormatter bformatter = new BinaryFormatter(); 
     bformatter.Serialize(stream, table); // out of memory exception here 
     Console.WriteLine(table.Rows.Count); 

     return; 
    } 

grazie in anticipo, George

Answer 1

Nota:?? DataTable il default è il formato di serializzazione XML che è stato utilizzato in . 1. *, che è incredibilmente inefficiente una cosa da provare è di commutazione per il più recente formato di:

dt.RemotingFormat = System.Data.SerializationFormat.Binary; 

---

Re out out of memory/2 GB; singoli oggetti .NET (come byte[] dietro a MemoryStream) sono limitati a 2 GB. Forse provare a scrivere su un FileStream?

(edit: no: ha provato che, ancora errori)

Mi chiedo anche se è possibile ottenere risultati migliori (in questo caso) utilizzando table.WriteXml(stream), forse con la compressione GZIP come se lo spazio è un premio.

Answer 2

1) Il sistema operativo è x64, ma l'app x64 (o anycpu)? In caso contrario, è limitato a 2 GB.

2) Si verifica "presto" o dopo che l'app è in esecuzione da un po 'di tempo (cioè n serializzazioni successive)? Potrebbe essere il risultato di una frammentazione dell'heap di oggetti di grandi dimensioni ...?

Answer 3

È interessante notare che in realtà aumenta fino a 3,7 GB prima di dare un errore di memoria qui (Windows 7 x64). Apparentemente, avrebbe bisogno di raddoppiare quell'importo per completarlo.

Dato che l'applicazione utilizza 1.65GB dopo la creazione della tabella, sembra probabile che sia colpire il 2GB byte[] (o qualsiasi singolo oggetto) Limite di Marc Gravell sta parlando di (1.65GB + 2GB ~ = 3.7GB)

In base a questo blog, suppongo che sia possibile allocare la memoria utilizzando WINAPI e scrivere la propria implementazione MemoryStream utilizzando tale. Cioè, se volessi davvero farlo. Oppure scrivi uno usando più di un array ovviamente :)

Answer 4

Come già discusso, questo è un problema fondamentale nel tentativo di ottenere blocchi contigui di memoria nella dimensione di Gigabyte.

si sarà limitato da (in difficoltà crescente)

1. La quantità di memoria indirizzabile
   • dal momento che sono a 64 bit questo sarà si 12GB di memoria fisica, al netto di eventuali buchi richiesto dai dispositivi più eventuali spazi per i file di scambio.
   • Si noti che è necessario eseguire un'applicazione con relevant PE headers that indicate it can run 64bit oppure si eseguirà in WoW64 e solo 4 GB di spazio indirizzo.
   • Si noti inoltre che il target predefinito era changed in 2010, un contentious change.
2. CLR's limitation that no single object may consume more than 2GB of space.
3. Ricerca di un blocco contiguo all'interno della memoria disponibile.

Si può scoprire che si esaurisce lo spazio prima del limite CLR del 2 perché il buffer supporto nel flusso si espande in un 'raddoppio' della moda e questo si traduce rapidamente nel buffer viene allocato nel Large Object Heap . Questo heap non viene compattato allo stesso modo degli altri heap (1) e di conseguenza il processo di creazione della dimensione massima teorica del buffer sotto i frammenti 2 del LOH in modo da non riuscire a trovare un blocco contiguo sufficientemente grande prima questo succede.

Così un approccio di mitigazione se siete vicino al limite è quello di impostare la capacità iniziale del torrente in modo tale che esso ha sicuramente spazio sufficiente fin dall'inizio tramite one of the constructors.

Dato che si sta scrivendo sul flusso di memoria come parte di un processo di serializzazione, sarebbe logico utilizzare effettivamente i flussi come previsto e utilizzare solo i dati richiesti.

• Se si esegue la serializzazione in una posizione basata su file, quindi eseguirne lo streaming direttamente.
• Se si tratta di dati che va in un database Sql Server considerare l'utilizzo di:
  • FILESTREAM 2008 solo ho paura.
  • Dal 2005 in poi si può read/write in chunks ma la scrittura è not well integrated into ADO.Net
  • Per le versioni precedenti al 2005, ci sono relativamente sgradevole workarounds
• Se si serializzare questo in memoria per l'uso in diciamo un confronto quindi prendere in considerazione lo streaming dei dati essendo paragonato e diffidente mentre procedete.
• Se si sta persistendo in memoria un oggetto per ricrearlo, questo in realtà dovrebbe andare in un file o in un file mappato in memoria. In entrambi i casi il sistema operativo è quindi libero di strutturarlo al meglio (nelle cache dei dischi o nelle pagine che vengono mappate dentro e fuori dalla memoria principale) ed è probabile che faccia un lavoro migliore di quello che la maggior parte delle persone è in grado di fare loro stessi.
• Se si esegue questa operazione in modo che i dati possano essere compressi, considerare l'utilizzo della compressione di streaming. Qualsiasi flusso di compressione basato su blocchi può essere facilmente convertito in una modalità di streaming con l'aggiunta di padding. Se la tua API di compressione non supporta questo in modo nativo, prendi in considerazione l'uso di uno che fa o scrive il wrapper per farlo.
• Se si esegue questa operazione per scrivere su un buffer di byte che viene quindi bloccato e passato a una funzione non gestita, utilizzare invece lo UnmanagedMemoryStream, che presenta una possibilità leggermente migliore di allocare un buffer di questo tipo di dimensione ma è ancora non garantito per farlo.

Forse, se ci dite che cosa voi stanno serializzazione di un oggetto di queste dimensioni per potremmo essere in grado di dirvi modi migliori per farlo.

---

1. Questo è un dettaglio di implementazione non si dovrebbe fare affidamento su