Wir haben eine .NET-Anwendung, die unsere Kunden für eine Massenimplementierung für zu groß halten, und wir würden gerne verstehen, was zu unserem Speicherbedarf beiträgt, und es ist möglich, alles zu tun, ohne .NET und wpf vollständig aufzugeben.Wie können Sie den verwalteten Heap in einer .NET-Anwendung untersuchen, um mögliche Speicheroptimierungen zu ermitteln?
Wir interessieren uns für beide Gesamtgröße zu verbessern und den privaten Arbeitssatz (pws). In dieser Frage möchte ich nur auf PWS schauen. VMMap meldet normalerweise einen PWS von 105 MB. Von dieser 11mb ist Bild, 31mb ist Heap, 52 mb verwaltet Heap, 7 mb ist private Daten und der Rest ist Stapel, Seite Tabelle usw.
Der größte Preis hier ist der verwaltete Haufen. Wir können ungefähr 8 MB des gemanagten Heaps direkt in unserem eigenen Code berücksichtigen, d. H. Objekte und Fenster, die wir erstellen und verwalten. Der Rest ist vermutlich .NET-Objekte, die von den Elementen des von uns verwendeten Frameworks erstellt wurden.
Was möchten wir tun ist, zu identifizieren, was Element des Rahmen Konto für welchen Teil dieser Nutzung und möglicherweise Wieder Architekt unser System ihre Verwendung zu vermeiden, wo möglich. Kann jemand vorschlagen, wie diese Untersuchung durchgeführt werden kann?
weitere Klarstellung:
Ich habe eine Reihe von Werkzeugen, so weit, einschließlich dem ausgezeichneten ANTS Profiler und WinDbg mit SOS verwendet, und sie erlauben mir die Objekte in dem verwalteten Heap zu sehen, aber wirklich von Interesse hier ist nicht "Was?", sondern "Warum?" Idealerweise würde ich gerne sagen können: "Nun, hier wurden 10 MB Objekte erstellt, weil wir WCF verwenden. Wenn wir unseren eigenen nativen Transport schreiben, könnten wir 8 MB davon mit x Qualitätsrisiko und Entwicklungsaufwand sparen."
eine gcroot auf 300.000 Objekte zu tun, ist nicht möglich.
Ich habe WinDbg worden, aber ich habe Schwierigkeiten, die Objekte in der Halde an die Rahmenelemente zu binden, die sie besitzen. Irgendwelche Ratschläge dazu? –
Eine Kombination von! Gcroot und! Dumpobj erledigt normalerweise meine Aufgabe. Wenn sich Ihr gesamter Code in einem gemeinsamen Namespace befindet, können Sie nicht einfach etwas wie! Dumpheap -stat-type YourCompaniesNamespace tun. Das gibt Ihnen die größten Speicherauslastungsklassen in Ihrem Code und Sie können sehen, ob es etwas gibt, das es wert ist, abgeholt zu werden. Alles, was du von WinDbg bekommst, sind Hinweise, du musst zurück in den Code springen, um diese Hinweise mit tatsächlichem Verhalten zu verknüpfen. –
Danke, das gibt mir eine Vorstellung davon, wo ich anfangen soll, ich glaube nicht, dass es zuviel Soße in unserem eigenen Namensraum gibt (wir haben bereits einen Optimierungszyklus durchgemacht), aber ich kann dies mit den bekannten Referenzen tun in unserem Projekt. Ich werde das ausprobieren und weitere Details hinzufügen. –