Ermitteln, welcher Garbage Collector ausgeführt wird

Sie arbeiten mit der Serverversion von Windows, Sie erhalten standardmäßig die Serverversion des Garbage Collectors. Das macht keine Hintergrundsammlungen, Müll wird von mehreren Threads gesammelt, so dass gelegentliche beobachtbare Pausen nicht ungewöhnlich sind. Sie können die Arbeitsstationsversion mit einer app.exe.config-Datei erzwingen:

Überprüfen Sie auch die Dokumentation für die Methode GC.RegisterForFullGCNotification () für eine Möglichkeit, mit den Nebeneffekten der Pausen umzugehen.

.NET Version 4.5 unterstützt Hintergrundsammlungen für den Server GC.

Ich habe diese Antwort erneut in meinem Blog gepostet: Ссылка

Sie können anhand zweier Methoden feststellen, welche Version von GC Sie verwenden:

1. ruft die System.Runtime.GCSettings.IsServerGC Eigenschaft
auf
2. Anfügen an den Prozess mit WinDbg und überprüfen, wie viele GC-Threads Sie verwenden den Befehl "! sos.threads" ohne die Anführungszeichen und (nach den folgenden Kriterien) ...

Sie haben nicht gesagt, welche Art von App Sie haben. Wenn Sie eine Konsolenanwendung, WinForm-App oder einen Windows-Dienst ausführen, erhalten Sie den Workstation-GC. Nur weil Sie auf einem Server-Betriebssystem laufen, heißt das nicht, dass Sie die Server-Version von GC erhalten. Wenn Ihre App nicht auf einem Computer mit mehreren Prozessoren gehostet wird, erhalten Sie standardmäßig den Eintrag Workstation GC - Concurrent. Wenn Ihre App auf einem Computer mit mehreren Prozessoren gehostet wird, erhalten Sie standardmäßig den ServerGC.

Jede selbst gehostete IIS- oder CLR-App wird standardmäßig im ServerGC-Modus ausgeführt.

Folgendes gilt für jeden .NET Managed Process:

Arbeitsstations-GC

• uni-proc-Maschine
• Deaktiviert immer Threads
• 1 ephemeraler GC Heap (SOH), 1 LOH GC Heap
• Läuft auf Thread, der GC ausgelöst hat
• Die Threadpriorität ist die gleiche wie der Thread, der GC
ausgelöst hat

Arbeitsstations-GC - gleichzeitig

• Läuft nur gleichzeitig in Gen2 / LOH (vollständige Sammlung)
• Gegenseitig mit dem Server-Modus
• Etwas größerer Arbeitssatz
• GC Thread verfällt, wenn es nach einiger Zeit nicht mehr verwendet wird
• 1 ephemeraler GC Heap (SOH), 1 LOH GC Heap
• Dedizierter GC-Thread
• Die Threadpriorität ist Normal

Server-GC

• Größere Segmentgrößen
• Schneller als Workstation GC
• Deaktiviert immer Threads
• 1 Ephemeraler GC Heap (SOH) für jeden logischen Prozessor (einschließlich Hyperthreading), 1 LOH GC Heap für jeden logischen Prozessor (einschließlich Hyperthreading)
• Dedizierte GC-Threads
• Die Threadpriorität ist THREAD_PRIORITY_HIGHEST

Es gibt nur einen Finalizer-Thread pro verwaltetem Prozess, unabhängig vom GC-Modus. Selbst während einer gleichzeitigen GC werden verwaltete Threads zweimal ausgesetzt (blockiert), um einige Phasen des GC auszuführen.

Eine selten bekannte Tatsache ist , dass Sie selbst dann, wenn Sie versuchen, den Server-Modus von GC festzulegen, nicht in Server-GC ausgeführt werden. Der GC bestimmt schließlich, welcher Modus für Ihre App optimal ist und überschreibt Ihre Einstellungen, wenn festgestellt wird, dass sich Ihre ServerGC-Einstellung negativ auf Ihre Anwendung auswirkt. Bei jeder gehosteten CLR-App werden alle manuellen GC-Einstellungen außer Kraft gesetzt.

In CLR 4.0 ändern sich die Dinge nur ein kleines bisschen

• Concurrent GC ist jetzt Hintergrund-GC
• Hintergrund-GC gilt nur für Workstation GC
• Alt (gleichzeitige GC):
  • Während einer vollständigen GC Zulässige Zuordnungen bis zum Ende der kurzlebigen Segmentgröße
  • Ansonsten werden alle anderen Threads angehalten
• Neu (Hintergrund-GC):
  • Ermöglicht bei Bedarf ephemere GCs gleichzeitig mit Hintergrund-GC
  • Leistung ist viel schneller
• Der Server-GC blockiert immer Threads zum Sammeln einer beliebigen Generation

In CLR 4.5 ändern sich die Dinge nur ein bisschen ... wieder

• Hintergrundserver-GC:
  • Server-GC blockiert nicht mehr. Stattdessen wird ein dedizierter Hintergrund-GC verwendet Threads, die gleichzeitig mit Benutzercode ausgeführt werden können - siehe MSDN: Hintergrundserver-GC

Somit haben alle Anwendungen in .NET 4.5+ jetzt Hintergrund-GC verfügbar , unabhängig davon, welchen GC sie verwenden.

.NET 4.7.1 GC Verbesserungen

.NET Framework 4.7.1 enthält Änderungen in Garbage Collection (GC), um die Zuordnungsleistung zu verbessern, insbesondere für Large Object Heap (LOH) -Zuordnungen. Dies ist auf eine Änderung der Architektur zurückzuführen, bei der die Zuweisungssperre des Heaps für Small Object Heap (SOH) und LOH in zwei aufgeteilt wird. Anwendungen, die viele LOH-Zuordnungen vornehmen, sollten eine Verringerung der Zuordnungskonfliktkonflikte sehen und eine bessere Leistung sehen. Diese Verbesserungen ermöglichen LOH-Zuordnungen, während Hintergrund-GC (BGC) SOH überstreicht. Normalerweise wartet der LOH-Zuordner die gesamte Dauer des BGC-Sweep-Prozesses, bevor er Anforderungen zur Speicherzuweisung erfüllen kann. Dies kann die Leistung beeinträchtigen. Sie können dieses Problem in GCStats von PerfView beobachten, wo eine 'LOH-Zuordnungspause (aufgrund des Hintergrund-GC)' vorliegt & gt; 200 ms Eventtabelle. Der Grund für die Pause ist "Warten auf BGC, um freie Listen zu erstellen". Diese Funktion sollte dazu beitragen, dieses Problem zu beheben.