Ich habe Probleme mit einer Windows 2012 R2-Maschine der Serverklasse, die gelegentlich ihren verwalteten .net-Heap auf über 10 GB erweitert (normalerweise sollten 1-2 GB sein). Ich habe Speicherabzüge in diesem Feld nach einer Gen2-Sammlung gemacht, um herauszufinden, welche Objekte auf dem Heap zugewiesen werden.
Verwenden von WinDbg / SOS
%Vor%erzeugt eine Liste von Objekten, von denen das größte ~ 150 MB Speicher ist, und läuft schnell ab. Ziehen Sie diese Ausgabe in Excel und addieren Sie die TotalSize, ich bekomme nur 1,5 GB Objekte (inline mit dem, was ich erwarte).
%Vor%Mein erster Gedanke ist, dass es ein nicht verwaltetes Speicherleck gibt, also habe ich den Heap mit
überprüft %Vor%was gezeigt hat, dass die Größe des GC-Heapspeichers tatsächlich 10 GB ist
%Vor%Ich habe bestätigt, dass der Speicher alle im Heap der 2. Generation (Performance Counter) ist, aber ich bin nicht sicher, wo ich von hier aus nach den fehlenden 8,5 GB verwalteten Objekten suchen soll.
Irgendwelche anderen Ideen / WinDbg / SOS-Befehle, um diese zu finden?
Die von !dumpheap angegebenen Größen sind die Größen der Typen selbst und nicht die tatsächlichen Größen der Instanzen.
Sie können !objsize verwenden, um die Größe einer Instanz aufzulisten. Da jedoch mehrere Instanzen Verweise teilen, erzeugen dieselben Objekte, die die Ausgabe von !objsize summieren, normalerweise auch ein inkorrektes Ergebnis.
Die Größe des verwalteten Heapspeichers lässt sich am besten ermitteln, indem Sie die von !dumpheap und !eeheap angegebenen Gesamtsummen betrachten.
Tags und Links memory-leaks memory .net c# windbg