Freigeben über

Konfigurieren der Garbage Collection in .NET

  • Artikel

Für eine gute Leistung ist es wichtig, die Garbage Collection in .NET für den Siloprozess richtig zu konfigurieren. Laut Erkenntnissen des Teams besteht die beste Kombination von Einstellungen bei gcServer=true und gcConcurrent=true. Sie können diese Werte im C#-Projekt (CSPROJ) oder in einer app.config konfigurieren. Weitere Informationen finden Sie unter Varianten der Garbage Collection.

.NET Core und .NET 5 und höher

Diese Methode wird bei Projekten im SDK-Stil nicht unterstützt, die für das vollständige .NET Framework kompiliert werden.

<PropertyGroup>
    <ServerGarbageCollection>true</ServerGarbageCollection>
    <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
</PropertyGroup>

.NET Framework

Projekte im SDK-Stil, die für das vollständige .NET Framework kompiliert werden, sollten dennoch weiterhin diese Konfigurationsart verwenden. Sehen Sie sich eine beispielhafte app.config-XML-Datei an:

<configuration>
    <runtime>
        <gcServer enabled="true"/>
        <gcConcurrent enabled="true"/>
    </runtime>
</configuration>

Dies ist jedoch nicht so einfach, wenn ein Silo als Teil einer Azure-Workerrolle ausgeführt wird, die standardmäßig für die Verwendung der Arbeitsstations-GC konfiguriert ist. Es gibt einen relevanten Blogbeitrag, in dem erläutert wird, wie Sie die gleiche Konfiguration für eine Azure-Workerrolle festlegen, siehe Server garbage collection mode in Azure.

Wichtig

Die Server-Garbage-Collection ist nur auf Computern mit mehreren Prozessoren verfügbar. Selbst wenn Sie die Garbage Collection entweder über die CSPROJ-Datei der Anwendung oder über die Skripts im genannten Blogbeitrag konfigurieren, können Sie daher nicht die Vorteile von gcServer=true nutzen, wenn das Silo auf einem (virtuellen) Computer mit einem Single-Core ausgeführt wird. Weitere Informationen finden Sie unter GCSettings.IsServerGC-Hinweise.