merkwürdige Nicht-Arbeitsspeicher-Ausnahme während der Serialisierung

Hinweis: DataTable verwendet standardmäßig das XML-Serialisierungsformat, das in 1. * verwendet wurde, was unglaublich ineffizient ist. Eine Sache zu versuchen ist Wechsel zu dem neueren Format :

Erneute Speicherkapazität / 2 GB; einzelne .NET-Objekte (z. B. byte[] hinter MemoryStream ) sind auf 2 GB beschränkt. Vielleicht schreibst du stattdessen in FileStream ?

(edit: nein: habe das versucht, immer noch Fehler)

Ich frage mich auch, ob Sie bessere Ergebnisse (in diesem Fall) mit table.WriteXml(stream) , vielleicht mit Kompression wie GZIP, wenn Platz ein Premium ist.

Wie bereits besprochen, ist dies ein fundamentales Problem beim Versuch, zusammenhängende Speicherblöcke in der Gigabyte-Größe zu erhalten.

Sie werden begrenzt durch (in steigendem Schwierigkeitsgrad)

1. Die Größe des adressierbaren Speichers
   • Da Sie 64bit sind, werden Sie 12 GB physischer Speicher haben, weniger Löcher, die von den Geräten benötigt werden, plus Speicherplatz für Auslagerungsdateien.
   • Beachten Sie, dass Sie eine App mit den relevanten PE-Headern ausführen müssen, die angeben, dass dies möglich ist führe 64bit aus oder du wirst unter WoW64 laufen und nur 4GB Adressraum haben.
   • Beachten Sie auch, dass das Standardziel in 2010 geändert , ein strittige Änderung .
2. Die Einschränkung CLR, dass kein einzelnes Objekt mehr als 2 GB Speicherplatz beanspruchen kann .
3. Einen zusammenhängenden Block innerhalb des verfügbaren Speichers finden.

Sie können feststellen, dass Ihnen vor dem CLR-Limit von 2 kein Speicherplatz mehr zur Verfügung steht, da der Sicherungspuffer im Stream "verdoppelnd" erweitert wird und dies schnell zur Zuweisung des Puffers im Large Object Heap führt. Dieser Heap wird nicht auf die gleiche Weise kompaktiert wie die anderen Heaps (1) und als Ergebnis zerlegt der Prozess des Aufbaus auf die theoretische maximale Größe des Puffers unter 2 das LOH, so dass Sie kein ausreichend großes zusammenhängendes finden blockieren, bevor dies geschieht.

Wenn Sie nahe an der Grenze sind, sollten Sie daher die Anfangskapazität des Streams so einstellen, dass vom Anfang an über genügend Speicherplatz über Einer der Konstruktoren .

Da Sie im Rahmen eines Serialisierungsprozesses in den Speicherstream schreiben, wäre es sinnvoll, Streams tatsächlich wie vorgesehen zu verwenden und nur die erforderlichen Daten zu verwenden.

• Wenn Sie zu einem dateibasierten Speicherort serialisieren, streamen Sie ihn direkt dorthin.
• Wenn dies Daten sind, die in eine SQL Server-Datenbank eingehen, sollten Sie Folgendes berücksichtigen:
  • FILESTREAM 2008, nur fürchte ich.
  • Ab 2005 können Sie in Chunks lesen / schreiben aber Schreiben ist nicht gut in ADO.Net integriert
  • Für Versionen vor 2005 gibt es relativ unangenehme Problemumgehungen
• Wenn Sie dies im Speicher serialisieren, um es zum Beispiel in einem Vergleich zu verwenden, dann ziehen Sie in Betracht, auch die Daten zu vergleichen, die verglichen werden, und zu diffundieren, während Sie weitermachen.
• Wenn Sie ein Objekt im Speicher persistieren, um es neu zu erstellen, dann sollte dies wirklich zu einer Datei oder einer Speicherabbilddatei gehen. In beiden Fällen ist das Betriebssystem dann frei, es so gut wie möglich zu strukturieren (in Disk-Caches oder Seiten, die dem Hauptspeicher zugeordnet werden), und es ist wahrscheinlich, dass es einen besseren Job macht, als die meisten Leute tun können sich selbst.
• Wenn Sie so vorgehen, dass die Daten komprimiert werden können, sollten Sie die Streaming-Komprimierung in Erwägung ziehen. Jeder blockbasierte Komprimierungsstrom kann ziemlich einfach in einen Streaming-Modus mit dem Hinzufügen von Auffüllen umgewandelt werden. Wenn Ihre Komprimierungs-API dies nativ nicht unterstützt, sollten Sie einen solchen verwenden, der dies tut, oder den Wrapper dafür schreiben.
• Wenn Sie dies tun, um in einen Byte-Puffer zu schreiben, der dann angeheftet und an eine nicht verwaltete Funktion übergeben wird, dann verwenden Sie UnmanagedMemoryStream statt dessen hat dies eine etwas bessere Chance, einen Puffer dieser Art zuzuteilen, was aber immer noch nicht garantiert ist.

Wenn Sie uns vielleicht sagen, was Sie für ein Objekt dieser Größe serialisieren möchten, können wir Ihnen vielleicht bessere Möglichkeiten geben, es zu tun.

1. Dies ist ein Implementierungsdetail, auf das Sie sich nicht verlassen sollten

1) Das Betriebssystem ist x64, aber ist die App x64 (oder anycpu)? Wenn nicht, ist es auf 2 GB begrenzt.

2) Erfolgt dies "früh" oder nachdem die App für einige Zeit ausgeführt wurde (d. h. n Serialisierungen später)? Könnte es vielleicht eine Folge der großen Objekt-Heap-Fragmentierung sein ...?

Interessanterweise geht es tatsächlich bis zu 3,7 GB, bevor hier ein Speicherfehler auftritt (Windows 7 x64). Offensichtlich würde es etwa doppelt so viel benötigen, um es fertigzustellen.

Da die Anwendung 1,65 GB nach dem Erstellen der Tabelle verwendet, scheint es wahrscheinlich, dass sie das Limit von 2 GB byte[] (oder irgendeines einzelnen Objekts) erreicht, von dem Marc Gravell spricht (1,65 GB + 2 GB ~ = 3,7 GB)

Basierend auf diesem Blog könnten Sie Ihren Speicher wahrscheinlich mithilfe von das WINAPI, und schreiben Sie Ihre eigene MemoryStream-Implementierung, die das verwendet. Das heißt, wenn Sie das wirklich wollen. Oder schreibe einen mit mehr als einem Array natürlich:)