Speicherleck finden

In Ihrer Analyse stelle ich fest, dass die .net-Analyse nicht korrekt durchgeführt wurde. Führen Sie die Analyse auf demselben Computer durch, auf dem Sie den Speicherauszug erfasst haben?

Damit debugdiag ordnungsgemäß funktioniert, muss auf dem Analysegerät dieselbe Version des .net-Frameworks (der Anwendung) installiert sein.

Bitte führen Sie keinen systemeigenen Speicher-Leak-Dump wie this durch, es sei denn, es wurde kein nicht verwaltetes Leck ermittelt. Aus Ihrer Analyse geht hervor, dass dies ein verwaltetes Leck ist.

Wenn Sie die Datei web.config geändert haben, wird eine Anwendungsdomäne entladen und neu geladen

Lassen Sie uns Schritt für Schritt tun

1. Verwenden von DebugDiag (Aufzeichnen aufeinanderfolgender Hang-Dumps)
   • Starten Sie DebugDiag Collection und wechseln Sie zur Registerkarte Prozesse  
   • Starten Sie Ihren Stresstest
   • Überprüfen Sie die Speichernutzung und erfassen Sie einen Hang-Dump , sobald die Speicherkapazität 1 GB erreicht hat.
     • klicken Sie mit der rechten Maustaste auf den Prozess w3wp.exe
     • wählen Sie die Option Create Full Memory Dump  
   • Erfassen Sie einen weiteren Speicherauszug mit 2 GB und einen mit 3,5 GB
   • Sie sollten Speicherauszüge im Ordner C:\ProgramFiles\DebugDiag\Logs\Misc\speichern.
   • Klicken Sie mit der rechten Maustaste auf die Speicherauszugsdatei und wählen Sie die Option .NET-Speicherproblem analysieren  

Vergleichen Sie nun die Analyse der einzelnen Speicherauszugsdateien (1 GB, 2 GB, 3,5 GB). Sie sollten feststellen, welche .NET-Objekte zunehmen und keinen Müll sammeln.

In der Speicheranalyse sollten Sie CLR-Informationen **** ,. NET GC-Heap-Informationen , Den meisten Speicher verbrauchen .NET-Objekte etc wie unten. Dies wird eintreten, wenn Ihre .net-Symbole durch die Debugdiag-Analyse korrekt identifiziert werden

CLR Information
 CLR version = 4.6.1648.0
 Microsoft.Diagnostics.Runtime version = 0.9.2.0
.NET GC Heap Information
Number of GC Heaps: 4 
Heap Size 0x4001ce8 (67,116,264) 
Heap Size 0x3d5cca0 (64,343,200) 
Heap Size 0x3f8b0d0 (66,629,840) 
Heap Size 0x3ccb0d0 (63,746,256) 
GC Heap Size 249.71 MBytes  
Total Commit Size  249 MB 
Total Reserved Size    17158 MB 

40 most memory consuming .NET object types

System.Char[]   193.01 MBytes    (12450 objects )
Free      45.21 MBytes    (4760 objects )
System.String      1.56 MBytes    (18072 objects ) 
==============trimmed out =======================

DebugDaig Eine automatisierte Analyse sollte Folgendes ergeben

1. ** Fehler oder Warnungen ** - Achten Sie genau auf Warnungen oder Fehler, die von der Debugdiag-Analyse oben im Bericht angezeigt werden.
2. .NET GC-Heap-Informationen - Gesamte Commit-Größe - Dies entspricht in etwa Ihrer .net-Speicherauslastung.
3. 40 speicherintensivste .NET-Objekttypen - Dies kann verwendet werden, um die Speichererhöhung in aufeinanderfolgenden Dumps zu vergleichen. Hier erfahren Sie, welche Objekte zu Problemen führen. Manchmal kommen einige Objekte, die Sie überhaupt nicht verwenden, und möglicherweise aus einer Drittanbieter-Bibliothek. Oder Sie sehen Objekte, die Sie selbst erstellt haben
4. Top-Objekte in der Finalizer-Warteschlange - Dies gibt Ihnen einen Hinweis darauf, ob Ihr Finalizer blockiert ist .Objects.Some ähnliche Probleme werden diskutiert hier und hier
5. Objekte auf dem Heap für große Objekte - Dies führt zu einer Speicherfragmentierung und einem Heap für große Objekte, die Objekte mit einer Größe von mehr als 85 KB enthalten.
6. Größe von Cache, Datentabellen, Anwendungsdomänen, dynamischen Assemblys usw. . Es ist keine gute Idee, eine große Anzahl von Anwendungsdomänen in einem Prozess zu haben

Bitte beachten Sie, dass die automatische Debugdiag-Analyse manchmal die Ursache nicht ermitteln kann und eine manuelle Analyse mit windbg erfordert. DebugDiag-Analyse finden Sie in diesem Video .

Hoffe das hilft!