.NET-Prozessspeicherauslastung = 5x CLR-Heapspeicher?

Question

Ich versuche, einige Speicherauslastungsprobleme zu beheben. Insgesamt sammelt meine Anwendung ein paar Datenwerte und visualisiert sie mit einem C1 WPF Charts und Datagrids schließlich alles in PDF-Berichte.

Profilerstellung meines Prozesses mit YourKit Ich bin mit der Situation konfrontiert, dass die CLR-Heap-Größe ~ 120 MB ist (was alles in Ordnung ist), während die Prozessspeichergröße ~ 580 MB beträgt. Das ist fast 5-mal der Speicherverbrauch meiner tatsächlichen CLR-Heap-Größe. Meine CLR-Peak-Größe war 220 MB gegenüber 710 MB Prozessspeicherzuweisung.

Ich bin mir bewusst, dass einige Overhead auf meinem Objekt Haufen, Stapeln und so weiter erforderlich ist. In Java-JVMs war der typische Faktor, um den ich mich gekümmert habe, ~ 1,5x.

Wie kann dieser übermäßige Speicheraufwand erklärt werden? Ordnen die Prozesse nur freien freien Heapspeicher zu? Wenn ja, erklärt dies die 710 MB im Vergleich zu 220 MB?

Answer 1

Ein paar zusätzliche Hinweise hier. Obwohl ich nicht sicher bin, was Sie mit "CLR Heap Size" meinen. Es ca. 8 verschiedenen Haufen, die die CLR verwendet - so dass der Speicher sehen Sie in der Heap-Größe vs. VM Größe Konten für einige der Differenz:

1. Loader Heap: enthält Strukturen CLR und das Typsystem
2. Hochfrequenz-Heap: Statik, MethodTables, FieldDescs, Interface-Karte
3. Low Frequency Heap: EEClass, Classloader und Lookup-Tabellen
4. Stub Heap: Stubs für CAS, COM-Wrapper, P/Invoke
5. Large Object Er ap: Speicherzuordnungen, die mehr als 85k Byte
erfordern
6. GC Heap: Benutzer zugewiesen Heap-Speicher privat an die App
7. JIT-Code Heap: Speicher zugewiesen durch mscoreee (Execution Engine) und der JIT-Compiler für verwalteten Code
8. Prozess/Base-Heap: Interop/unmanaged Zuweisungen, nativen Speicher usw.

Zwei andere Gegenstände, die übermäßige Speichernutzung sind Speicherfragmentierung verursachen kann (meist auf der LOH auftritt oder große Objektheap) oder eine hohe Anzahl von Threads.

Es gibt viele Ursachen für die Speicherfragmentierung, und die beste Möglichkeit, dies auszuschließen, besteht darin, WinDbg zum Analysieren der Segmentgrößen für jedes Segment auf dem GC Heap zu verwenden.

Für eine große Anzahl von Threads steht Ihnen für jeden Thread, den Ihre App verwendet, 1 MB Stapelspeicherplatz zur Verfügung. Dieser Speicher befindet sich im Prozess/Basis Heap. Wenn Sie also 100 Threads haben, haben Sie zusätzliche 100 MB Speicherverbrauch.

HTH

Answer 2

Wenn die Gesamtgröße der verwalteten Heaps erheblich kleiner ist als die von Ihrer Anwendung verwendeten privaten Bytes, weisen Sie wahrscheinlich nicht verwalteten Speicher zu und verwahren ihn (möglicherweise) nicht ordnungsgemäß. Grafikobjekte, Streams und andere Objekte, die IDisposable implementieren, müssen ihre Dispose()-Methode aufgerufen haben, bevor sie außerhalb des Gültigkeitsbereichs liegen oder in einer using(){}-Anweisung platziert werden, damit alle nicht verwalteten Ressourcen bereinigt werden. Ein Tool wie ANTS Memory Profiler kann Ihnen zeigen, wie Ihr Speicher zugewiesen wird und welche Objekte IDisposable implementieren.