Kann reservierten Speicher verursachen eine Out of Memory-Ausnahme

Question

Wir haben einen 32-Bit-Windows-Dienst, der Speicher verliert - OutOfMemory Ausnahme wird ausgelöst. Es ist ausführbare .net 4.0-Datei auf Windows-Server 2003 ausgeführt. Beim Debugging von Crash-Dump-Dateien mit WinDbg, sehe ich, dass der größte Teil des Speichers tatsächlich reserviert und nicht verpflichtet ist.

Wie man es von WinDbg Screenshot sehen kann, gibt es 2,5 Gb unklassifizierter Speichernutzung, und das meiste davon 2,1 Gb ist eigentlich reservierten Speicher (MEM_RESERVE). Ich habe Erfahrung, Crush-Dumps zu debuggen, aber dieses Szenario ist etwas Neues für mich. MEM_COMMIT ist OK verlassen - 564,270 Mb, verwalteten Heap der Größe ca. 82 Mb ist

Ich habe auch einheimische Haufen zu sehen, wenn es große Brocken von Daten erhalten sind, konnte aber nichts Verdächtiges dort finden entweder

Also meine Frage ist - ist es möglich, dass MEM_RESERVED in OOM Ausnahme führen könnte? Wenn ja, wie kann ich es debuggen, warum/wie viel Speicher wird reserviert? Wo sonst würden Sie suchen, um herauszufinden, was das Problem sein könnte?

Wenn weitere Informationen erforderlich sind, bitte fragen Sie danach, und ich werde meine Post aktualisieren.

Answer 1

Ja, das Reservieren von Speicher kann OutOfMemoryException auslösen. Versuchen Sie, ein paar sehr große Byte-Arrays zuzuweisen. Der Speicher für diese wird nicht festgelegt, bis Sie in den Inhalt der Arrays schreiben. Sie können OOM jedoch einfach auslösen, indem Sie diese Arrays zuweisen.

Ich kenne die Implementierungsdetails nicht, aber da VirtualAlloc fehlschlägt, wenn es eine Reservierungsanforderung nicht berücksichtigen kann, gehe ich davon aus, dass die CLR dies in eine Ausnahme übersetzt. Ich sehe nicht, wie es eine fehlgeschlagene Reservierungsanfrage in etwas Nützliches verwandeln könnte, also ist eine Ausnahme eine vernünftige Wahl.

Answer 2

OutOfMemoryException tritt auf, wenn das System nicht mehr virtuellen Speicher für Ihre Anwendung zuweisen kann. Reservierter Speicher ist virtueller Speicher und berücksichtigt daher diese Grenze.

Sie können, dass in C++ versuchen am einfachsten:

while(::VirtualAlloc(NULL, 65536, MEM_RESERVE, PAGE_READWRITE) != NULL); 
std::cout << "All memory reserved. Now check with tools." << std::endl; 

Wenn VirtualAlloc() NULL zurück, es könnte nicht mehr memoy zuordnen. In WinDbg wird dies zeigen

MEM_RESERVE 32307 7f6f2000 (1.991 Gb) 99.59% 99.56% 

jedoch VirtualAlloc() keine Zuteilung von Speicher auf dem Heap, so !heap in diesem Fall nicht sinnvoll ist, und zeigt nur die Standard-Prozess-Heap:

0:000> !heap 
Index Address Name  Debugging options enabled 
    1: 00440000 

Es ist die Andersherum: Der Heap-Manager verwendet VirtualAlloc(), um den Speicher abzurufen. Beachten Sie auch, dass .NET den Heap-Manager ebenfalls nicht verwendet. Es reserviert auch Speicher direkt mit VirtualAlloc() und verwaltet es dann eigenständig. Also, weil Sie es in der Ausgabe von !heap sehen können, ist es kein .NET-Problem, es ist ein natives Speicherproblem.

In meinem naiven Verständnis die gflags Einstellung Enable heap tagging by DLL sollte hilfreich sein, um die Quelle einer Heap-Zuordnung zu bestimmen. Meine Erwartung, dass der Befehl !heap -t einfach den Namen der DLL anzeigen würde, die den Speicher zugewiesen hat, wurde jedoch nicht erfüllt.