My ASP.NET Core 2.2 web-application, running on .NET Framework 4.7.2, uses over 220MB+ after startup at idle.
220MB is high - because it runs in a small Azure App Service Plan, I wanted to see what could be done to reduce memory usage. Visual Studio's Diagnostics Tools window says that the managed object heap only accounts for 11MB of that 220MB.
Unsatisfied with that explanation (where's the other 209MB going?!) I used VMMap to take a look and it reported 85MB of the process' private-bytes were different Managed Heaps - not the 11MB that Visual Studio reports.
Here's a screenshot:
I understand that the 11.5MB heap that Visual Studio reports in the Memory Snapshot probably corresponds to the first child row in VMMap (the Gen0 heap using 11,523 K) - but what about the other heaps of a similar size (10.3MB, 9.9MB, 9.4MB, 9.0MB, 5.7MB) - what's inside of those and why isn't VS reporting them? If they aren't relevant to the application then why is the process' memory usage so high when it isn't running under the Debugger?
After some research - I found an explanation at explains most of the heaps:
By default ASP.NET Core programs run using the "server" GC system, which creates a separate Managed Heap instance for each processor core - and all these heaps map to a single logical managed heap.
So the 11.5MB heap size is true - but it means there's six 11.5MB heaps on my computer: one for each processor core (though their sizes are not actually, 11.MB - they're close enough: 10.3MB, 9.9MB, 9.4MB, 9.0MB, 5.7MB - because fewer objects were placed in those core-specific heaps)
This is somewhat explained in this page here: https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals - look for the heading "Workstation and server garbage collection".
Still - I wasn't expecting this. I was hoping for something like an informative XML comment inside my
app.config/web.config-file generated by Visual Studio where it actually puts<gcServer enabled="true" />in the default project template.