Freigeben über

DA0018: 32-Bit-Anwendung wird an den vom Prozess verwalteten Speicherlimits ausgeführt

  • Artikel

Regel-ID

DA0018

Kategorie

Verwendung der Profilerstellungstools

Profilerstellungsmethode

Sampling

Meldung

Die verwalteten Speicherbelegungen erreichen beinahe das Standardlimit für einen 32-Bit-Prozess. Die Anwendung ist möglicherweise speichergebunden.

Regeltyp

Warnung

Wenn Sie mit der Sampling-, .NET-Arbeitsspeicher- oder Ressourcenkonfliktmethode Profile erstellen, müssen mindestens 10 Samplings erfasst werden, damit diese Regel ausgelöst wird.

Ursache

Die bei der Profilerstellung erfassten Systemdaten deuten darauf hin, dass sich die .NET Framework-Arbeitsspeicherheaps der maximalen Größe angenähert haben, die verwaltete Heaps in einem 32-Bit-Prozess erreichen können. Diese maximale Größe ist ein Standardwert. Er basiert auf der Gesamtmenge des Prozessadressbereichs, der für private Bytes belegt werden kann. Der gemeldete Wert ist der Maximalwert der Heaps, der ermittelt wurde, während der Prozess, dessen Profil erstellt wird, aktiv war. Führen Sie eine erneute Profilerstellung unter Verwendung der Methode zur .NET-Speicherprofilerstellung aus, und optimieren Sie die Verwendung verwalteter Ressourcen durch die Anwendung.

Wenn sich die Größe der verwalteten Heaps dem Standardlimit nähert, muss unter Umständen die automatische Garbage Collection häufiger aufgerufen werden. Dadurch vergrößert sich der Mehraufwand für die Speicherverwaltung.

Die Regel wird nur für 32-Bit-Anwendungen ausgelöst, die auf 32-Bit-Computern ausgeführt werden.

Regelbeschreibung

Die Microsoft .NET-CLR (Common Language Runtime) verfügt über einen automatischen Speicherverwaltungsmechanismus, durch den der Speicher von Objekten, die von der Anwendung nicht mehr verwendet werden, mithilfe eines Garbage Collectors freigegeben wird. Der Garbage Collector ist generationsorientiert, da angenommen wird, dass viele Speicherbelegungen kurzlebig sind. Lokale Variablen müssen beispielsweise kurzlebig sein. Neu erstellte Objekte beginnen in Generation 0 (gen 0) und werden zu Generation 1, wenn sie nach einer Ausführung der Garbage Collection noch vorhanden sind, und schließlich zu Generation 2, wenn sie von der Anwendung auch weiterhin verwendet werden.

Verwaltete Objekte, deren Größe 85 KB übersteigt, werden im großen Objektheap belegt. Hier werden Garbage Collection und Komprimierung seltener ausgeführt als bei kleineren Objekten. Große Objekte werden separat verwaltet, da für sie von einer höheren Beständigkeit ausgegangen wird und da das Mischen von beständigen, großen Objekten mit häufig belegten, kleineren Objekten zu einer starken Fragmentierung des Heaps führen kann.

Wenn sich die Gesamtgröße der verwalteten Heaps dem Standardlimit nähert, nimmt der Mehraufwand für die Speicherverwaltung häufig so weit zu, dass sich dies negativ auf die Reaktionszeit und die Skalierbarkeit der Anwendung auswirkt.

Vorgehensweise bei der Überprüfung einer Warnung

Doppelklicken Sie im Fenster "Fehlerliste" auf die Meldung, um zur Ansicht Markierungen zu navigieren. Suchen Sie die Spalten .NET CLR-Speicher\Anzahl der Bytes in den Heaps und Festgelegte Bytes insgesamt. Ermitteln Sie, ob das Maß an verwalteter Speicherbelegung in bestimmten Phasen der Programmausführung besonders hoch ausfällt. Vergleichen Sie die Werte der Spalte Anzahl der Bytes in den Heaps mit der Garbage Collection-Rate aus den Spalten .NET CLR-Speicher\Auflistungsanzahl der Generation 0, .NET CLR-Speicher\Auflistungsanzahl der Generation 1 und .NET CLR-Speicher\Auflistungsanzahl der Generation 2, um zu ermitteln, ob sich das Muster der verwalteten Speicherbelegung auf die Garbage Collection-Rate auswirkt.

In einer .NET Framework-Anwendung wird die Gesamtgröße der verwalteten Heaps durch die Common Language Runtime auf einen Wert beschränkt, der knapp der halben Maximalgröße des privaten Teils eines Prozessadressbereichs entspricht. Bei einem 32-Bit-Prozess, die auf einem 32-Bit-Computer ausgeführt werden, beträgt die Obergrenze des privaten Teils des Prozessadressbereichs 2 GB. Wenn sich die Gesamtgröße der verwalteten Heaps dem Standardlimit nähert, nimmt unter Umständen der Mehraufwand für die Verwaltung des Arbeitsspeichers zu, während die Leistung der Anwendung abnimmt.

Wenn ein hoher Speicherverwaltungsaufwand ein Problem ist, ziehen Sie eine der folgenden Optionen in Betracht:

  • Optimieren Sie die Verwendung verwalteter Speicherressourcen durch die Anwendung.

    - oder -

  • Umgehen Sie die architektonischen Einschränkungen für die maximale Größe von virtuellem Arbeitsspeicher für 32-Bit-Prozesse.

Wenn Sie die Verwendung von verwalteten Speicherressourcen optimieren möchten, sammeln Sie im Rahmen einer .NET-Speicherbelegungsprofilerstellung Daten zur verwalteten Speicherbelegung. In den .NET-Arbeitsspeicherdatenansichten der Profilerstellungstools finden Sie Informationen zum Speicherbelegungsmuster der Anwendung.

Ermitteln Sie mithilfe der Objektlebensdaueransicht, welche von den Datenobjekten des Programms bei der Generierung noch vorhanden sind und von dort aus freigegeben werden.

Ermitteln Sie mithilfe der .NET-Speicherbelegungsansicht den Ausführungspfad, der zu diesen Speicherbelegungen geführt hat.

Weitere Informationen zum Verbessern der Garbage Collection-Leistung finden Sie auf der MSDN-Website im technischen Artikel zu .NET Framework: Garbage Collector-Grundlagen und Tipps zur Leistung.

Wenn Sie den architektonischen Einschränkungen für virtuellen Arbeitsspeicher hinsichtlich der Größe des privaten Teils eines Prozessadressbereichs entgehen möchten, führen Sie diesen 32-Bit-Prozess auf einem 64-Bit-Computer aus. Einem 32-Bit-Prozess stehen auf einem 64-Bit-Computer bis zu 4 GB an privatem, virtuellem Arbeitsspeicher zur Verfügung.

Einem 64-Bit-Prozess stehen auf einem 64-Bit-Computer bis zu 8 TB an virtuellem Arbeitsspeicher zur Verfügung. Ziehen Sie die Neukompilierung der Anwendung in Betracht, um sie als systemeigene 64-Bit-Anwendung auszuführen. Diese Regel dient nur als Information. Möglicherweise sind keine Korrekturmaßnahmen erforderlich.