Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
For good performance, it's important to configure .NET garbage collection correctly for the silo process. Based on the team's findings, the best combination of settings is gcServer=true
and gcConcurrent=true
. You can configure these values in your C# project (.csproj) or an app.config file. For more information, see Flavors of garbage collection.
.NET Core and .NET 5+
This method isn't supported for SDK-style projects compiling against the full .NET Framework.
<PropertyGroup>
<ServerGarbageCollection>true</ServerGarbageCollection>
<ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
</PropertyGroup>
.NET Framework
SDK-style projects compiling against the full .NET Framework should still use this configuration style. Consider an example app.config XML file:
<configuration>
<runtime>
<gcServer enabled="true"/>
<gcConcurrent enabled="true"/>
</runtime>
</configuration>
However, this isn't as easy if a silo runs as part of an Azure Worker Role, which defaults to using workstation GC. A relevant blog post discusses how to set the same configuration for an Azure Worker Role; see Server garbage collection mode in Azure.
Important
Server garbage collection is available only on multiprocessor computers. Therefore, even if you configure garbage collection via the application .csproj file or the scripts in the referred blog post, you won't get the benefits of gcServer=true
if the silo runs on a (virtual) machine with a single core. For more information, see GCSettings.IsServerGC remarks.