Blazor server memory leak occurs after page reloads

[peskovaa]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

After multiple page reloads, memory is allocated (Heap gen0 - Heap gen1 - Heap gen2). Multiple Blazor control instances stay in memory.

Expected Behavior

The number of Blazor component instances remains the same after a page reload.

Steps To Reproduce

1. Add a custom Blazor component to the page;

2. Make a memory snapshot (I used dotMemory);
   

3. Reload the page several times for memory allocation (Heap gen0 - Heap gen1 - Heap gen2);

4. Make a memory snapshot.

It has 2 or more instances of your custom component:

Exceptions (if any)

No response

.NET Version

6.0

Anything else?

No response

[javiercn]

Thanks for contacting us @peskovaa

Thanks for contacting us @nikiGagliardi.

This is very likely not a memory leak unless:

• You are able to cause an OutOfMemoryException on the application.
• Proof that Blazor is holding on to the memory.
• Proof that your app is not holding on to the memory.

If you are able to provide a repro project and traces that proof the three things above, we will be happy to take a look at it. Otherwise, we have already tested these areas thoroughly and we have not found evidence of a leak, so it is very likely there is something your app is doing or there is a gap between the framework understanding of a memory leak and your definition for it.

A few important notes to take into consideration when measuring memory:

• Are you running the published version of the app?
• Has the app been published in Release mode?
• Have you made sure to not attach a debugger to the running app?
• Did triggering a Gen 2 forced, compacting collection GC.Collect(2, GCCollectionMode.Aggressive | GCCollectionMode.Forced, blocking: true, compacting: true)) frees the memory?
• Is your app allocating objects on the large object heap?
• Did you test the memory growth after the app warmed up? Typically, there are caches that get populated when code executes for the first time that add a constant amount of memory to the footprint of the app.

Another key points of information that you might be missing are:

• Server GC will not trigger garbage collections until it determines it is absolutely necessary to do so, to avoid freezing your app, and considers that your app is the only thing running on the machine (so it can use all the memory in the system).
• Even when a GC is triggered, .NET will hold on to the memory instead of returning it to the OS immediately as it is very likely that it will reuse it the near future. This avoids committing and decommitting memory constantly, which is expensive.
• You'll see this reflected if you use dotnet-counters because you'll see the GCs happen and the amount of used memory go down to 0, but you will not see the working set counter decrease (that's the sign that .NET is holding on to the memory to reuse it).

You can see a lot of the statistics about how memory in your app is behaving using dotnet-counters. For more information see here

You can read more about it here

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.