Determining which garbage collector works

Question

I run a large .NET 4.0 x86 application on Windows Server 2003 x64 (2x Xeon 4 core processes) and I encounter problems when my application freezes ~ 2-3 times a day for 30 seconds and then resumes work as usual. The application restarts only once a week and consumes 400-800 mb of memory, so I assume that these freezes are garbage collection. I see only hangs in the logs, not live, or I would check the task manager to confirm.

I am trying to figure out which .Net 4 GC is working, and how to either switch the GC to a new parallel gc background, if it is not, or how to actually confirm that GCs (Procmon does not show .Net tools on Win2k3 server).

Answer 1

You are running a server version of Windows, you will receive a server version of the default garbage collector. What background collections do not do, garbage is collected in multiple threads, so randomly observed pauses are not unusual. You can force change the version of the workstation with the app.exe.config file:

<configuration> <runtime> <gcServer enabled="false"/> </runtime> </configuration> 

Also check out the docs for the GC.RegisterForFullGCNotification () method for a way to eliminate the side effects of pauses.

.NET version 4.5 will support background collections for the GC server.

Answer 2

I republished this answer on my blog: http://dave-black.blogspot.com/2012/04/how-to-determine-which-garbage.html

You can determine which version of GC you are using with two methods:

1. calling the System.Runtime.GCSettings.IsServerGC property
2. joining a process using WinDbg and checking how many GC threads you use with the "! sos.threads" command without quotes and (according to the criteria below) ...

You did not say which application you have. If you use a console application, a WinForm application, or a Windows service, you will get a GC workstation. Just because you are running on a server OS does not mean that you will get a GC version for GC. If your application is not hosted on a machine with multiple processors, by default you will get a GC workstation - Concurrent. If your application is hosted on a machine with multiple processors, you will get Servers by default.

Any stand-alone IIS or CLR application will run in ServerGC mode by default.

The following apply to any given .NET managed process:

GC Workstation

• uni-proc machine
• Always pause threads
• 1 Ephemeral GC Heap (SOH), 1 LOH GC Heap
• Runs on a thread that starts the GC
• The priority of the thread is the same as the thread that initiated the GC

GC Workstation - Parallel

• Runs only in parallel in Gen2 / LOH (full collection)
• Mutual Exception with Server Mode
• Slightly larger working set
• GC Thread expires if not used after some time
• 1 Ephemeral GC Heap (SOH), 1 LOH GC Heap
• GC dedicated thread
• Flow Priority - Normal

GC server

• Large segment sizes
• Faster than a GC workstation
• Always pause threads
• 1 Ephemeral GC Heap (SOH) for each logical processor (including hyperthreading), 1 LOH GC Heap for each logical processor (including hyperthreading)
• Dedicated GC Streams
• Stream Priority - THREAD_PRIORITY_HIGHEST

There is only 1 Finalizer thread per managed process, regardless of GC mode. Even during a parallel GC, the managed threads are twice suspended (blocked) to complete some phases of the GC.

It is rarely known that even if you try to set the GC server mode, you may not work in the GC server; GC ultimately determines which mode is best for your application, and WILL redefines your settings if it determines that the ServerGC setting will negatively affect your application. In addition, any hosted CLR application running on a single processor machine will have any manual GC settings that are overridden - in this case, the CLR will always use the GC mode of the workstation.

In CLR 4.0 things change a bit

• Currently gc
• Help GC only applies to workstation GC
• Old (parallel to GK):
  • During full-scale permitted distributions to the final ephemeral segment size
  • Otherwise, pauses all other threads.
• New (background GC):
  • Allows the use of ephemeral GCs simultaneously with the background GC, if necessary
  • Performance is much faster
• GC server always blocks threads for collection of any generation

In CLR 4.5, things change a bit ... again

• GC Background Server:
  • The GC server is no longer blocked. Instead, it uses dedicated GC GC threads that can run concurrently with the user code - see MSDN: GC Background Server

Thus, in .NET 4.5+ all applications now have access to the GC, regardless of which GC they use.

.NET 4.7.1 GC Enhancements

The .NET Framework 4.7.1 makes changes to garbage collection (GC) to improve distribution performance, especially for large object (LOH) distributions. This is due to an architectural change to split the heap allocation lock by 2, for a heap of small objects (SOH) and LOH. Applications that make many LOH distributions should see reduced distribution blocking competition and see better performance. These improvements enable LOH distribution, while Background GC (BGC) sweeps SOH. Typically, the LOH distributor waits for the entire duration of the BGC sweep process before it can satisfy the memory allocation requests. This may interfere with work. You can observe this problem in PerfViews GCStats, where there is a pause in LOH distribution (due to GC background)> 200 ms. Event table. Reason for pause: “Waiting for BGC for streaming lists. This feature should help mitigate this problem.